0DTE Confluence

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 discloses exact scoring threshold, the ET trading window, the level requirement, and the fallback to latest alert when alert_json is omitted. It doesn't state read-only or error behavior, but 'check' implies a non-mutating operation and the presence of an output schema covers return shape.

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 compact sentences front-load the core gate criteria before parameter behavior. No filler; every clause adds distinct information.

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 tool has only two optional parameters, an output schema exists, and the description supplies the key gate conditions plus param selection behavior. Slight ambiguity remains around what 'level present' means and where the score originates, but these are domain details rather than blocking 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?

With 0% schema description coverage, the description compensates by explaining alert_json's role (check a specific record) and the default latest-alert behavior. It doesn't explicitly name the use_latest parameter or specify the alert_json string format, but the relationship between the two parameters is clear enough for invocation.

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 establishes a clear evaluation role: a Tier-1 gate with explicit pass conditions (score >= 6/8, ET time window, level present). It is distinguishable from siblings like get_latest_alert because it is a gate/check rather than a retrieval. Minor omission: no explicit verb like 'checks whether', but the name and criteria make intent clear.

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 useful context: it is the Tier-1 gate, and it can operate on a specific alert_json or fall back to the latest alert. However, it doesn't name sibling alternatives or state when not to use this tool, so the agent must infer routing from sibling names.

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 behavioral disclosure burden, but it only reveals the +/-25% rule. It does not disclose whether this is a pure calculation, whether it modifies any state, how alert_json or use_latest influence behavior, or what kind of output is returned beyond 'levels'.

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 short and packs the threshold percentages into one sentence, but the unexplained 'E' and the ambiguous 'scale/stop' phrasing create avoidable confusion. Conciseness is achieved at the expense of clarity, so it is only marginally acceptable.

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?

Although an output schema exists, the description fails to explain how the inputs map to the computation, lacks any annotation context, and omits usage guidance. For a tool with three parameters and one required field, this is insufficient for reliable 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%, so the description must compensate, but it only obliquely hints at entry_premium through 'fill price E'. alert_json and use_latest are completely unaddressed, leaving most of the parameter semantics unspecified and forcing the agent to guess.

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 operation on a resource ('Scale/stop premium levels') and gives concrete thresholds (+25% target, -25% cap), so it is not a tautology. However, the verb phrase 'scale/stop' is ambiguous, and the symbol 'E' is unexplained, leaving the tool's overall purpose vague for an agent without domain-specific context.

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 about when to use this tool versus alternatives like plan_robinhood_entry or other alert-related siblings. The description does not state prerequisites, exclusions, or a decision context, so an agent must rely on 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?

With no annotations, the description carries the full burden. It discloses the calculation window (rolling 5-min) and asset set, and clarifies it is not a trigger. However, it does not mention what the output represents, how many data points are included, or any limitations; some of this is likely covered by the output schema.

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 sentences with no filler. The core metric and asset list are front-loaded, and the usage caveat is immediate and memorable.

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 zero-parameter tool with an output schema present, the description provides sufficient context: the metric, the assets, and the intended role. It could add a bit more about how to interpret the correlation grid or when to favor it over sibling correlation tools, but the essentials are covered.

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, so there is no parameter semantics burden. The baseline of 4 applies, and the description adds useful context about the assets and rolling return methodology even though no parameters need explanation.

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 a specific metric (rolling 5-min return correlation) and the exact resources (SPY/QQQ/IWM/DIA). It also positions the tool as a portfolio overlay rather than a signal trigger, which separates it from alert-style siblings, though it does not name a specific alternative.

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?

"Portfolio overlay, not a trigger" gives clear guidance on when to use it: as background context for portfolio assessment, not as an entry/exit trigger. It provides a useful exclusion but stops short of naming alternatives or explicit when-to-use conditions.

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 provided, the description carries the behavioral burden. It usefully discloses that this is an overlay rather than a trigger and identifies the data source, but it does not mention update cadence, whether values are delayed, or how the output is structured. The provided output schema partially compensates.

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 phrases with no filler. It front-loads the instrument list and immediately follows with the key usage caveat, making every word earn 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 zero-parameter tool with an output schema, the description is nearly complete: it names the assets, labels the use case, and sets the 'not a trigger' boundary. It could add a sentence on data freshness or intended pairing with other tools, but nothing essential is missing 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?

The tool has zero parameters, so the schema fully documents the input surface and the description adds no parameter-level detail. This is the appropriate baseline for a no-parameter 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 the exact instruments (VIX, 10Y/TNX, dollar/UUP) and states the tool's role as a 'risk-tone overlay'. This distinguishes it from sibling market tools like get_fear_greed or get_macro_events, though it lacks an explicit verb such as 'retrieves' or 'returns'.

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 'Risk-tone overlay — not a trigger' clearly tells the agent to use this as background context rather than as a standalone alert or entry signal. It does not name alternative tools, such as get_latest_alert, but the exclusion is explicit and actionable.

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 disclosure burden. It does disclose that the tool provides real-time data, uses Lee-Ready logic, and supports 1m/5m intervals, but it leaves unclear what 'Pro tier' implies and whether the result is a snapshot or a series.

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 method and metric. The 'Pro tier. interval: 1m | 5m' portion is terse and slightly awkward, but there is no redundant 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?

Given an output schema exists and the tool has only two simple parameters, the description is reasonably complete for basic invocation. However, it fails to mention the instrument parameter, potential default behavior, or how this tool fits among related liquidity and order-flow tools.

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 must compensate. It documents the allowed interval values ('1m' | '5m') but completely omits the instrument parameter, which is a significant gap given the schema provides no descriptions either.

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 operation: it aggregates Net CVD using Lee-Ready on minute bars, which is a specific and distinctive computation. It does not explicitly contrast itself with sibling tools like get_order_flow or get_liquidity_concentration, but the unique CVD focus makes the purpose recognizable.

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 does not say when to use this tool versus alternatives such as get_order_flow or get_liquidity_concentration. It only notes 'Pro tier' as a possible access constraint, which is not usage 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only retrieval, how the 'board' is structured, whether access or subscription constraints apply, or what operational behavior the agent should expect despite the 'Bundle tier' fragment.

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 appropriately short and front-loads the core contents. The trailing 'Bundle tier.' is cryptic and adds little operational value, but it does not bloat the overall description.

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 annotations, no parameter guidance, and no usage context relative to similar get_* tools, the description is not sufficient for an agent to confidently select this tool over get_swing_structure or get_market_clock. The output schema helps with return value shape, but the intended context and access implications are left unclear.

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%, and the description never mentions the symbol parameter or its SPY default. The agent must rely entirely on the property name and default, while the description adds no semantic value to parameter understanding.

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 as a 'Daily Structure Board' and enumerates concrete contents: automated pivots, ATR targets, and overnight boundaries. This goes beyond a tautology and gives the agent a clear sense of what the tool provides, though it does not explicitly distinguish it from sibling tools like get_swing_structure.

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 word 'Daily' and the listed contents imply the tool is relevant when an agent needs daily pivot, ATR, or overnight-boundary context. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternative tools, so usage must be inferred rather than stated.

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; it usefully discloses that the output is a 1σ band computed from ATM IV for only the remaining session. It does not describe the exact output shape or edge cases, but as a read-only getter it does not hide destructive or mutating behavior.

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 one tight, front-loaded phrase with no filler; every word ('1σ', 'ATM IV', 'remaining session') contributes distinct information.

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?

Because an output schema exists, the return shape does not need explanation, and the tool is simple with a single optional parameter. However, the missing usage guidance and implicit parameter linkage leave the definition only minimally 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 0% and the description does not mention the symbol parameter or explicitly connect it to the underlying used for the expected-move calculation. The parameter name and default 'SPY' make it self-explanatory enough to avoid a 1, but the description adds no parameter meaning.

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 ('expected-move band') and specifies its derivation ('from ATM IV') and horizon ('remaining session'), so an agent can distinguish it from sibling market-data tools like get_skew or get_pin. It lacks a verb, but the get_em tool name and the noun phrase make the action 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 'remaining session' qualifier implies the intended use case, but the description gives no explicit when-to-use or when-not-to-use guidance and names no alternatives. An agent must infer context from the sibling list rather than being told.

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 provided, the description carries the behavioral disclosure burden. It adds useful context by naming the inputs (Tape + VIX) and specifying the intraday timeframe, but it does not explicitly state that the call is read-only, how often it updates, or what output scale to expect, though an output schema is present.

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 one short line that front-loads the core meaning and then adds a concise usage hint. There is no filler or repetition, and every word earns its place even though 'rail' is domain-specific jargon.

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?

Given the tool has zero parameters and an output schema, the description provides enough context about the metric and its intraday nature to allow invocation. It could be more complete by explaining when to prefer this over related sentiment tools, but that is a usage- guidance gap rather than a critical disclosure gap.

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 input schema is empty with 100% schema description coverage, so there are no parameters for the description to clarify. The baseline of 4 applies because nothing additional is needed.

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 that the tool returns an intraday fear/greed composite composed of Tape and VIX, which identifies the resource and scope. It does not explicitly name a sibling alternative, but the metric name and qualifiers are specific enough to distinguish it from most sibling tools like get_skew or get_correlation_grid.

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 'Intraday fear/greed composite' implies use when an intraday sentiment reading is needed, and 'Fade extremes at a rail' hints at a mean-reversion trading context. However, there is no explicit guidance on when to use this tool versus the many sibling tools, nor any exclusions or conditions.

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 provided, the description carries the full burden of behavioral disclosure, but it only states what the output is about. It does not mention read-only nature, default symbol behavior, how 'near spot' is defined, or what happens when data is unavailable—though the output schema does cover return shape, the description adds no behavioral context.

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 extremely concise and front-loaded, with no wasted words. However, it is arguably too terse: it is only a noun phrase, not a full sentence, and omits information that would help an agent use the tool correctly. It earns its keep as a summary but not as a complete instructional description.

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 existence of an output schema covers return-value structure, and the single optional symbol parameter lowers complexity. But the description leaves key contextual gaps: what 'near spot' means, how the symbol parameter interacts with the profile, and when this tool should be preferred over siblings. For a tool with no annotations and no parameter descriptions, this is insufficiently 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?

The schema has one parameter, 'symbol', with no description, and schema description coverage is 0%. The tool description does not mention the symbol parameter, its default value, or how it affects the returned profile. The meaning of the parameter is entirely left to inference from the tool name and default value.

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 'Per-strike GEX profile near spot' identifies a specific resource (a GEX profile) and implicitly the action (retrieve/get), and the GEX-specific wording helps distinguish it from the many other get_* siblings. However, it lacks an explicit verb and does not clarify what 'near spot' precisely means, leaving minor ambiguity.

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 the many sibling tools such as get_skew or get_path_risk_score. There is no mention of use cases, exclusions, or alternatives. It is not misleading, but it offers no usage direction.

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 of behavioral disclosure, but it only states the data source and scope. It does not explain how the optional date behaves when omitted, how limit and min_score affect results, whether events are sorted, or any pagination behavior. The phrase 'graded events' hints at scoring, but that is not enough for a tool with no annotation safety or behavior hints.

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 with no filler or repetition. It packs the key scope ('multi-day', 'historical', 'scanner log') into a compact phrase. However, it is thin enough that it misses important semantic detail, so it earns a strong but not perfect conciseness score.

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?

Given three optional parameters, no annotations, low schema coverage, and many sibling tools, this description is not complete enough for an agent to invoke the tool confidently. The output schema may document return shape, but the description still fails to clarify parameter semantics, default behavior for date, or when to choose this over get_replay_today. The core selection and invocation context 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 0%, so the description must compensate for explaining all parameters. It only covers 'date' with 'optional YYYY-MM-DD', and does not explain 'limit' or 'min_score' at all. The one parameter it does mention adds some meaning, but the other two are left completely 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?

The description clearly identifies the resource as 'multi-day historical graded events from scanner log' and indicates an optional date parameter. It lacks an explicit action verb like 'retrieve' or 'list', but the tool name plus the resource scope make the purpose reasonably clear. The 'multi-day' qualifier also helps distinguish it from get_replay_today.

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 about when to use this tool versus alternatives such as get_replay_today or list_alert_history. The phrase 'multi-day historical' implies past-date usage, but it never explicitly says 'use this for historical replays' or 'use get_replay_today for the current day's replay'. The agent is left to infer the selection 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It mentions the computed signals and index choices, but it does not clarify whether the tool is read-only, what time window or data source is used, or what 'health' means operationally beyond the two metrics.

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 core content is short and front-loaded, but the fragment 'Bundle tier.' adds no actionable information, and the parameter hint is formatted as a terse inline leftover. It is compact but not every part 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?

Given low complexity, a single optional parameter, and an output schema, the description is minimally viable: it states the subject matter and the parameter choices. However, it lacks any broader context for when to use the tool, and the cryptic 'Bundle tier.' line slightly undermines clarity.

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%, but the description partially compensates by specifying the allowed values: index: 'SPY' | 'QQQ'. It does not explain that these are tickers or how the value affects the result, but the parameter name and default make the meaning reasonably self-evident.

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 resource as an 'Index Health Dashboard' and the substance as 'relative volume & momentum for top components,' which goes beyond a simple restatement of the name. It does not use an explicit verb like 'retrieve' or 'show,' but the intent is clear and distinguishable from the sibling market tools.

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 guidance about when to use this tool, what question it answers, or which sibling tool might be a better alternative. The only practical hint is the allowed index values, so an agent must infer the appropriate context on its own.

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 must carry the behavioral burden by itself. It does add useful context: the alert comes from Discord, is restricted to A+/B, and requires a separate _pro_eligble verification before sizing. But it does not disclose staleness, possible absence of an alert, or failure behavior; those gaps are partially mitigated by the zero-param signature and presence of an output schema.

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, each earning its place: the first states the core output precisely, the second adds an actionable caveat. There is no filler, repetition, or re-statement 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 zero-argument read tool with an output schema, the description is nearly complete: it identifies source, grade, and a usage condition. It could be even more robust by explicitly naming alternatives or the appropriate selection context, but nothing about parameters or return shape is left unexplained.

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 0 parameters and schema coverage is effectively 100%, so the description is not required to explain parameter semantics. In such a zero-param case, the baseline is 4, and the description does not need to compensate.

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 operation ('latest'), the resource ('Discord-posted A+/B alert'), and even identifies the source channels. This is far more specific than a tautological 'get_latest_alert' and lets an agent tell it apart from unrelated get_* tools, though it does not explicitly contrast with close siblings like list_alert_history or check_alert_tradeable.

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 one concrete instruction: check _pro_eligble before sizing, which implies the alert alone does not guarantee sizeability. However, it never explicitly says when to select this tool over the sibling alternatives, so the deiion of 'when not to use it' 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. It discloses that the tool is advisory, has liquidity gates, and does not auto-execute — useful behavioral context — but it does not explicitly state read-only status, data freshness, or response behavior beyond the existing output schema.

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 deliver the key point and the most important caveat with no filler. The advisory stance is front-loaded and the anti-execution warning is immediately actionable.

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 zero-parameter tool with an output schema, the description covers the essential context: purpose, timeframe, single-name scope, liquidity gating, and non-execution. The only minor gap is that 'liquidity gates' is not expanded, but the output schema can carry that detail.

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 the schema is fully covered, so the description has no parameter burden. The baseline of 4 applies because no parameter explanation is needed.

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 a specific resource — a single-name 0DTE Friday board — and its advisory nature. It is clear enough to distinguish from execution-oriented siblings like plan_robinhood_entry, though it does not explicitly contrast with related get_* board tools.

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 conveys when to use it (Friday, single-name 0DTE context) and explicitly warns it is not auto-exec, which tells the agent not to route it to execution. However, it does not name alternative tools or exclusion conditions relative to siblings.

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 communicates that the tool returns macro-economic events with volatility forecasts and implies an overview-style read-only panel. However, it does not explain what 'Bundle tier' means, how current the data is, or any limitations.

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 very short and front-loaded with the main subject. However, 'Bundle tier' is unexplained jargon that slightly reduces clarity; otherwise the sentence is tight and wastes no 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?

The output schema covers the return shape, and the zero-parameter schema lowers complexity. Still, the description omits practical context such as when to choose this over get_major_news or get_market_clock, and 'Bundle tier' is not clarified. 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?

The tool has zero parameters, so no parameter documentation is needed. The empty schema already covers everything, and 'Bundle tier' suggests a fixed bundled output requiring no arguments. Baseline for zero-parameter tools is 4.

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 resource as high-impact economic events and adds the key differentiator of volatility forecasts, which distinguishes it from news-focused siblings like get_major_news. It lacks an explicit verb, but combined with the tool name 'get', the intent is reasonably clear.

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 guidance on when to use this tool instead of alternatives. 'Bundle tier' hints at packaging but not at the appropriate use case. The agent receives no exclusions, prerequisites, or comparisons to sibling tools.

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. The 'Context only — never a trigger' clause discloses a non-obvious behavioral trait: this tool is passive and must not be used to drive a trade or alert decision. However, nothing else is disclosed about recency, source coverage, output shape, or failure behavior, which is a noticeable gap for a tool with zero annotation support.

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 entire description is nine well-placed words across two sentences. The resource ('MAJOR RSS headlines') is front-loaded, and the behavioral guardrail ('never a trigger') follows immediately. Every word earns its place with zero waste.

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 zero-parameter tool with an output schema present, the description provides enough to invoke it correctly and understand its general role. The output schema presumably documents the return structure, so the main missing piece is the source or selection criteria for what qualifies as 'MAJOR' headlines, which is a minor gap.

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, and the rubric grants a baseline of 4 in this case since there is nothing for the description to document. The input schema is an empty object, and the description correctly adds no parameter details that would be redundant or invented.

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 resource ('RSS headlines') with a scope qualifier ('MAJOR'), making the tool's purpose as a news-context fetcher clear. The clause 'never a trigger' and sibling names like check_alert_tradeable and get_latest_alert make the distinction from action-oriented tools apparent. It doesn't specify which RSS sources or what 'major' means, so the purpose is clear but slightly underspecified.

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?

'Context only' explicitly frames when to use the tool (for gathering background/news context) and 'never a trigger' is an explicit when-not. However, it does not name any alternative tools, even though over 18 siblings exist, so an agent must infer the routing from the exclusion rather than being pointed to a specific sibling.

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 of behavioral disclosure. It conveys that the tool reports session state and related windows, implying a read-only lookup, but does not explicitly state that it is non-destructive, nor mention any timing/caching nuances. This is acceptable for a zero-param getter but not rich behavioral context.

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 one dense, front-loaded line with no filler. Every phrase — 'open/closed', 'force-flat time', 'lane windows' — adds information. It is an appropriately sized definition for a simple no-argument getter.

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 zero-parameter tool with an output schema, the description reasonably covers the semantic categories returned. It doesn't explain the meaning of 'force-flat time' or 'lane windows', but the output schema can carry return-value detail. It lacks usage context, though that is already penalized under usage guidelines.

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 parameters and schema coverage is 100%, so the description has no parameter semantics to add. The baseline of 4 is appropriate because there is nothing missing for invoking the tool with an empty argument object.

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 resource ('session state') and enumerates the specific outputs it provides: open/closed, force-flat time, and lane windows. Although it is a noun-fragment rather than a full verb phrase, the tool name starts with 'get', so the action is unambiguous. It is specific enough to distinguish it from other market-data siblings.

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 given about when to use this tool versus sibling tools, and no alternatives or exclusions are mentioned. The agent must infer from the name and output fields that this is the go-to source for session clock status, which is not explicitly stated.

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 of behavioral disclosure. It describes the card's contents but does not state that this is a read-only operation, whether it can return empty results, or any data freshness or availability behavior. The 'get' prefix implies read-only, but nothing beyond that is disclosed.

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 concise fragment, roughly ten words, and gets straight to the point. Every word adds signal about the card's contents. It could be improved with a verb and clearer sentence form, but it is appropriately sized for a parameterless tool.

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 zero-parameter tool with an output schema present, the description covers the core payload concept. However, the jargon 'Tier-0' is unexplained, and there is no mention of when the card is available (e.g., market hours, after close) or any fallback behavior. The output schema presumably fills return-value details, but usage context remains thin.

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 the input schema is an empty object, so schema coverage is trivially 100%. Per calibration, a zero-parameter tool gets a baseline of 4; the description adds clarifying content about what the returned card includes, which is sufficient.

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 ('Tier-0 morning desk card') and lists its key contents (rails, IV rank, gap, events), making it clear this is a composite daily overview. It is distinct from sibling tools like get_rails or get_iv, though it doesn't explicitly contrast itself. The lack of an explicit verb is a minor gap.

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 implies a morning desk use case but does not state conditions, exclusions, or mention any sibling tool. An agent must infer from the name and context.

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 of behavioral disclosure. It reveals that the score is dynamic and derived from spread plus tick variance, and flags Pro-tier access. However, it does not state whether the value is bounded, what higher/lower scores mean, or what the output contains, leaving notable 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 compact sentence that front-loads the core idea and adds the access note second. Every phrase contributes information, with no fluff or repetition.

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 tool is simple, has one optional parameter, and an output schema exists, so the description does not need to explain return values. It explains what the score is based on and Pro-tier access, but lacks usage context and score interpretation guidance, which an agent would benefit from.

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% and the description does not mention the 'instrument' parameter. However, the parameter is a single optional string with a clear name and default value (SPY), so semantic risk is low. The description adds no parameter-specific meaning, but the schema's title and default provide basic clarity.

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 tool computes a 'dynamic execution risk score' from 'spread + tick variance,' identifying the specific resource and method. It does not explicitly differentiate it from sibling tools, but the metric's composition is unique enough to disambiguate it from other get_* tools.

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 about when to use this tool versus alternatives. The 'Pro tier' note hints at access restrictions but does not explain intended use cases, prerequisites, or situations where another tool would be more appropriate.

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?

There are no annotations, so the description carries the full burden, but it only states what the tool returns and gives no behavioral traits such as whether it performs computation, fetches live data, has side effects, or how the heuristic is derived. The name implies read-only, but the description adds little beyond that.

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 with no filler. It is appropriately compact for a simple one-parameter getter, though the brevity comes at the cost of needed context.

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 low-complexity tool with one optional parameter and an output schema, the description is minimally viable: it identifies the resource and the symbol scope. However, it does not explain what the pin/magnet score means or when an agent should prefer this tool, so the context is incomplete for a non-domain-expert agent.

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 has one parameter, 'symbol', with 0% description coverage, but the description only repeats the word 'symbol' without explaining valid values, formatting, or the meaning of the default SPY. It does not compensate for the schema's lack of semantic 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?

The description names the exact resource ('Pin score / magnet heuristic') and ties it to a symbol, so an agent can tell this tool is for retrieving a pin/magnet reading for a single ticker. It is specific enough to stand apart from the many get_* siblings, though the jargon is not explained in plain 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?

No guidance is given for when to use this tool versus alternatives, nor any exclusions or prerequisites. The only implied usage is 'when you need a pin score,' but the description does not place it in a broader decision context among the sibling tools.

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 must carry the full burden. It does communicate that this is a read-style analytics tool and adds the useful access constraint 'Pro tier', plus the conceptual output of theta decay by session window. However, it does not disclose rate limits, authentication specifics, or anything about response shape beyond the existence of an output schema.

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 in the first sentence. The Pro tier note and structure enum are relevant, but the enum could have been formatted more cleanly as a list or valid-values note rather than a bare label.

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 one-parameter tool with an output schema, the description is adequate for a basic call: it names the tool's purpose, gives valid values, and notes Pro tier. It falls short on contextual completeness because it never clarifies the term 'premium compression', explains what a session window is, or differentiates this tool from adjacent analytics tools in the same suite.

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 description coverage is 0%, but the description compensates by enumerating the allowed structure values: iron_condor, vertical_spread_call, vertical_spread_put, single, short_call, short_put. It does not explain what each structure means or which one to choose for a given scenario, but it clearly identifies the valid inputs beyond the bare schema definition.

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 resource as a Premium Compression Heatmap and specifies the metric: theta decay velocity by session window for a multi-leg structure. It is specific enough to distinguish this from most sibling analytics tools, though it does not explicitly contrast it with any named alternative.

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 guidance on when to use this tool versus the many option-related siblings like get_gex_profile, get_skew, or get_rails. The description implies use when theta decay compression data is needed, but it provides no exclusions, prerequisites beyond 'Pro tier', or alternative 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?

There are no annotations, so the description bears the full burden of behavioral disclosure. It conveys that the output is a live gamma map with specific elements, but it does not disclose data source, update cadence, market-hours dependencies, or any caveats about the 'magnet' or 'flip' indicators. The output schema may help, but the description itself remains 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?

The description is a single packed sentence that front-loads the key resource and its distinguishing content elements. There is no wasted wording, and given the zero-parameter input schema, this level of brevity is appropriate.

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 covers the core subject but leaves significant context gaps: it does not explain the jargon ('walls, flip, magnet, regime'), specify when the data is meaningful, or differentiate from closely related gamma tools. The presence of an output schema helps with return structure, but the lack of usage context and behavioral caveats makes this incomplete for an agent choosing among many similar market-analysis tools.

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, so parameter semantics are effectively moot. The description does not need to explain inputs, and the simple factual label is sufficient for a no-argument call.

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 ('SPY 0DTE gamma map') and lists the key content dimensions ('walls, flip, magnet, regime'), making the purpose reasonably clear. It distinguishes itself from generic tools, though it does not explicitly contrast with siblings like get_gex_profile or get_pin.

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 given about when to use this tool versus alternatives such as get_gex_profile, get_pin, or get_path_risk_score. The phrases 'Live SPY 0DTE' imply a real-time use case, but there is no explicit when-to-use, when-not-to-use, or alternative routing information.

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 behavioral disclosure burden. It only states 'educational replay', which hints at non-actionable or historical context, but does not explain data recency, scoring semantics, absence behavior, or why a caller might need this versus live tools.

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 compact sentence with no filler. The temporal scope is front-loaded and the 'educational replay' qualifier adds useful context without bloating the definition.

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 timeline with an output schema, the core idea is present, but the description is too thin: it omits parameter semantics and usage routing, and offers no behavioral context that the agent could not infer from the tool name 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?

Schema description coverage is 0%, and the description mentions neither limit nor min_score. It does not explain how these parameters affect the returned timeline, leaving the agent to guess from names and defaults alone.

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: today's timeline of graded candidates, with an 'educational replay' qualifier. This distinguishes it from get_hist_replay on temporal scope, though it lacks a direct verb and leaves 'graded candidates' somewhat 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?

No guidance is given for when to use this tool versus siblings like get_hist_replay, get_morning_desk, or get_latest_alert. The temporal 'today' hint is helpful, but there is no explicit context or 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?

With no annotations, the description carries the behavioral disclosure burden. It does add value by naming the three output regime buckets and the HAR-lite model, but it does not disclose staleness, lookback window, limitations, or any other behavioral 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?

The description is short and front-loaded with the model and output categories. The 'not Trapdoor wall trust' phrase is cryptic and may not earn its place, but the overall length and ordering are appropriate.

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?

Given zero annotations and a cryptic one-line description, an agent cannot confidently determine when to invoke this tool or how to interpret the result semantically. The output schema helps with return shape, but not with the meaning of the regime buckets, data scope, or invocation context.

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%, and the description says nothing about the 'symbol' parameter. The parameter is self-evident from its name and default value, but the description still fails to add any guidance on accepted symbols or behavior when omitted.

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 resource (realized volatility) and the output classification (Calm / Elevated / Explosive), which is more specific than the name alone. However, it relies on unexplained jargon such as 'HAR-lite' and 'Trapdoor wall trust' and does not explicitly say it returns a regime classification.

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 guidance on when to use this tool versus its many get_* siblings. The parenthetical 'not Trapdoor wall trust' hints at a distinction but provides no actionable context for an agent deciding between tools.

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. It does disclose a meaningful trait: the data is derived 'from Tradier chain' and includes a flag, which hints at source and derived nature. However, it does not mention permissions, rate-limit behavior, failure modes, or whether any state is written; the 'get' verb softens this gap, but the description itself is light on behavioral guarantees.

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 sentence with no filler; it names the output components and the data source in under a dozen words. It is appropriately short for a simple tool, though it could be slightly clearer with an explicit verb and a usage hint.

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?

Given no annotations and an output schema presumably covering return fields, the description still leaves selection guidance completely unaddresed. An agent must guess whether this tool is appropriate for skew/flattening analysis versus related options-structure tools, and there is no mention of common edge cases or how the flag should be interpreted.

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% and the single 'symbol' parameter has no description. The description does not explain how the symbol maps to the skew computation or what values are expected, and the default of SPY is the only semantic hint. While the parameter is simple and self-evident, the description still fails to compensate for the missing schema documentation.

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?

Naming the tool is 'get_skew' but the description gives a concrete domain outcome: an IV smile/skew strip plus a wing-fatening flag sourced from a Tradier chain. It clearly identifies the analytical object and distinguishes it from other get_* siblings such as GEX profiles or correlation grids, even though it lacks an explicit verb.

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 choose this tool over alternatives like get_pin, get_rails, or get_gex_profile. There are no stated conditions, use cases, or exclusions; an agent must infer that skew analytics is the intended use because of the name and description 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It does not state whether this is a read-only lookup, what data source it pulls from, how the divergence is computed, what the output represents, or any other behavioral 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?

The description is extremely terse, but it is under-specified rather than appropriately concise. 'SPY↔QQQ rails divergence feather' is not a complete statement of purpose or behavior, so the brevity does not serve the agent.

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?

Despite an output schema existing, the description still fails to explain the tool's core function, expected use, or relationship to sibling indicators. This is effectively an opaque label, and the agent would need external knowledge to call or interpret this 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?

The tool has zero parameters, so the input schema carries no burden and the description does not need to explain parameter semantics. The baseline of 4 applies because there is nothing missing on this dimension.

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 gives a resource ('SPY↔QQQ rails divergence') but no clear verb or explanation of what the tool actually does. Terms like 'feather' and 'rails' are unexplained jargon, making the purpose ambiguous. It does not meaningfully distinguish itself from sibling tools such as get_vrp_divergence or get_cross_asset.

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 guidance on when to use this tool versus any of its many siblings. The description is a bare phrase with no context, use cases, or exclusions, so an agent has no way to choose it over the related divergence and market indicator tools.

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 discloses key behavioral traits: the expiry selection rule, the 5–45 DTE window, the explicit 0DTE exclusion, and the Bundle/Pro access requirement.

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 tight, front-loaded sentence contains all essential information: data type, expiry selection, exclusion, and access tier. There is no filler or repetition.

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?

An output schema exists, so return shape does not need describing. The description covers the main decision-relevant details: what is returned, on which expiry, and what access is required. It only lacks explicit routing among sibling tools.

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% and the description adds no direct parameter guidance. However, the only parameter is a common 'symbol' field with a default of SPY, which is self-explanatory to an agent, so the lack of elaboration is not a major obstacle.

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 gets weekly/swing gamma walls plus 1σ EM on the nearest 5–45 DTE expiry. It also differentiates itself from intraday/0DTE tools by explicitly saying 'not 0DTE' and using 'swing'.

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 this is for swing/weekly horizon gamma analysis and explicitly excludes 0DTE, which helps with timing. However, it does not name sibling alternatives or explain when to choose this over related tools like get_daily_structure or get_gex_profile.

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 full behavioral burden. It only says 'Live', implying real-time data, but does not disclose caveats, update behavior, data source, or any operational constraints.

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 short and front-loads the term 'Live Confluence Tape', but it sacrifices clarity for brevity. Its few words are more jargon-laden than informative, so it earns only a middling conciseness score.

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 parameters, invocation is simple, but the description gives an agent almost no conceptual handle on what data is returned or what 'coded flow, OFI, quadrant' concretely mean. An output schema exists, but the description alone is too incomplete to support confident 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?

The tool has zero parameters and the input schema is empty, so no parameter semantics are needed. The output schema exists and can document return values; the description does not need to compensate for missing parameter documentation.

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 resource ('Confluence Tape') and hints at content ('coded flow, OFI, quadrant'), but it is a fragment rather than an explicit statement of what the tool does. The meaning is heavily domain-specific and does not help distinguish get_tape from siblings like get_rails or get_replay_today.

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 guidance on when to use this tool versus alternatives. The sibling list is large and includes many similar get_* tools, yet the description provides 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 carries the full burden of behavioral disclosure. It does not state whether the tool is read-only, whether it computes or fetches data, or what operational constraints apply. 'Bundle tier' hints at access level but does not explain behavior.

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 compact line with no filler. The opening label 'VRP Divergence Index' immediately communicates the core concept. 'Bundle tier' is cryptic but does not bloat the text.

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 zero-parameter tool with an output schema available, the description provides the essential metric definition needed to select and invoke the tool. It could add interpretation or eligibility context, but the minimal invocation surface makes this largely 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?

The input schema has zero parameters, so there is nothing for the description to clarify. Baseline 4 for zero-parameter tools is appropriate; the metric definition is sufficient.

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 metric, 'VRP Divergence Index', and defines it as 'ATM straddle IV vs realized variance', which clearly identifies the tool's purpose. It is distinguishable from the sibling set by naming a distinct volatility-risk-premium concept, though 'Bundle tier' adds little 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?

Usage is implied by the metric definition: an agent would select this when it needs the VRP divergence index. However, the description does not explicitly say when to prefer it over related siblings such as get_rv_regime or get_premium_compression_data, nor does it give 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?

There are no annotations, so the description carries the behavioral burden. It does disclose useful behavioral context: the data is 'Delayed' and sourced from 'official FRED'. However, it does not mention units, update cadence, or whether 2s10s is a spread, leaving some behavioral ambiguity.

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 compact, front-loaded phrase that uses every word meaningfully: delay status, source, and exact tenor composition. There is no filler or redundant restating of the schema.

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 zero-parameter read-only tool with an output schema present, the description gives enough context: source, latency, and exact series. The only real gap is explicit usage routing, which was already penalized in usage guidelines, so the tool remains adequately specified for an agent to call it confidently.

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, so there is nothing for the description to clarify beyond the schema. This earns the baseline of 4; no parameter documentation is needed or expected.

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 exact financial resource: official FRED 10Y / 2Y / 2s10s yield curve data. Even though it lacks an explicit verb, the tool name 'get_yield_curve' plus this resource specificity makes the purpose unmistakable and distinct from sibling tools.

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 should be used when the agent needs FRED 10Y/2Y/2s10s curve data, but it does not explicitly state when to use it versus alternatives or when not to use it. With many market-data siblings, some explicit routing guidance would strengthen this dimension.

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 burden. It discloses the data source, the date scope, and the sort order (newest first). It does not mention timezone handling, empty-result behavior, or access/rate constraints, so it is adequate but incomplete.

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. It front-loads the core scope and ordering information, and every word adds value.

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 tool is a simple read-only list operation and has an output schema, so the completeness burden is moderate. The description is enough to invoke it, but the gate definitions and parameter meanings are left ambiguous.

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 must compensate for the lack of parameter documentation. It does not explain 'limit' or 'min_score'; the reference to 'same gates as #alerts-a/#alerts-b' loosely hints at score thresholds, but the semantics remain implicit.

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 ('list') and resource ('alert history'), then narrows it further with today's Discord-posted A+/B and newest-first ordering. This clearly distinguishes it from the get_* and check_* sibling tools.

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 gives a clear context: use this for today's Discord-posted A+/B alerts using the same gates as #alerts-a/#alerts-b. It does not explicitly name alternatives or exclusions, but the scope is specific enough to route an agent 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?

Because no annotations are provided, the description must carry the behavioral disclosure burden. It does so meaningfully by stating 'Advisory only — does not place orders,' a critical non-effect that agents must know before invocation. It also implies plan construction rather than execution, but it does not disclose details like error behavior or whether any state is persisted. The core behavioral trait is nevertheless clearly communicated.

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 compact sentences with no filler. The core purpose is front-loaded, and the safety-relevant advisory-only clarification is placed immediately after. Every sentence 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?

With no annotations and zero schema description coverage, the description leaves important context missing: the meaning of use_latest, the expected format of alert_json, and selection guidance among sibling tools. An output schema exists, so return values do not need explanation, but the invocation details are insufficiently specified for reliable use.

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 must compensate for both parameters. The alert_json parameter is partially inferable from 'from alert', but use_latest is completely unexplained — its behavior, default implications, and relationship to alert_json are absent. The description names plan components but does not map them to parameters, leaving a real semantic gap for the agent.

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's action ('Build Robinhood execution plan from alert') and scope, naming the inputs it consumes (delta band, spread gate, budget, bracket, MCP steps). It is distinct enough from siblings like format_bracket_plan, though it does not explicitly reference a sibling to differentiate itself, so it stops just short of a 5.

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 building an advisory execution plan from an alert and explicitly notes it does not place orders. However, it gives no explicit when-to-use vs. when-not-to-use guidance or references to alternatives among the sibling tools, leaving the agent to infer the appropriate context.

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 of disclosing behavior. It only names the content ('min score and session window') but does not say whether this is a static reference, a computed summary, or how the values relate to alert generation. With zero annotation coverage and no behavioral detail, this is a significant gap.

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 concise sentence that front-loads the core resource ('Pro alert criteria') and immediately specifies the two key pieces of information. It contains no padding, repetition, or irrelevant detail.

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 zero-parameter tool with an output schema present, the description is largely complete: it tells an agent what topic the output covers. The main shortfall is the lack of any contextual framing about how 'min score' and 'session window' relate to the pro alert system, but the output schema can carry the detailed return structure.

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 schema description coverage is 100%, so the schema fully documents the input surface. The description adds meaning about what the output covers, which is appropriate. The baseline for 0-parameter tools is 4, and nothing here reduces that.

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 resource ('Pro alert criteria') and the key content ('min score and session window'), which is distinct from the sibling tools that retrieve live alerts or check tradeability. However, it lacks an explicit verb like 'returns' or 'summarizes', so the action is implied rather than stated.

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 guidance on when to use this tool versus alternatives such as get_latest_alert or check_alert_tradeable. The description implies this tool provides criteria definitions, but it does not state a use case, prerequisites, or exclusions.

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