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

Annotations already declare readOnlyHint=true, so the description correctly aligns with that. It adds significant behavioral context: large payload size (100-300 KB), a refusal condition (results over 1 MB are refused with RESULT_TOO_LARGE), and the need for per-bar context. No contradiction; the description complements the annotations well.

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 concise and front-loaded: it opens with the core purpose and immediately notes the large payload and sibling alternative. Every sentence adds value, with no fluff or repeated schema 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?

For a read-only tool with no output schema, the description covers what the agent needs to know: what it returns, when to use it, size concerns, failure mode, and how to extend the time range. It's complete for a complex tool with 6 parameters and nested objects.

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 only 17%, so the description must compensate. It explains the 'from' parameter (unix seconds for history) and implies the 'indicator' parameter through 'calculator output'. It doesn't detail 'config' or 'provider' but covers the key ones for usage. This is a strong compensation given the low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'FULL calculator output — every per-bar plot array AND the metadata envelope' is specific and distinguishes it from the sibling get_indicator_signal. It also clearly identifies the verb (get) and resource (full indicator output), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use only when the agent needs per-bar context; otherwise prefer get_indicator_signal', which routes the agent to the correct sibling. Also provides guidance on the optional 'from' parameter for loading history beyond the default window.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior; the description goes beyond by disclosing that only the metadata envelope is returned and that config/provider alter indicator defaults and data source. It does not discuss error or absence-of-signal behavior, but given the annotation coverage, the disclosure is solid.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences deliver purpose, return-scope, use case, and optional parameters without filler. Core information is front-loaded and every sentence contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only signal query with a nested config object and no output schema, the description names the returned top-level fields and key invocation options. It leaves some return-structure detail implicit, but an agent can select and invoke the tool correctly based on this definition.

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 only 20%, so the description must carry parameter meaning, and it does for the two ambiguous optional parameters: config overrides indicator defaults and provider forces a bar provider. The required parameters are illustrated by the BTC/15m example, though the config object's possible keys are still underspecified.

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 verb/resource ('latest signal envelope' for indicator, symbol, resolution) and contrasts it with full per-bar plot arrays, which differentiates it from siblings like get_indicator_full. The concrete use-case query makes intent 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?

It gives an explicit use case ('what is sniperV3 saying about BTC on 15m right now?') and explains the optional config/provider behavior. It does not explicitly name when not to use it or direct the agent to get_indicator_full for plot arrays, though that alternative is strongly 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: max 20 indicators per call, unknown keys fail the whole call before any fetch, and there's no built-in voting rule. It also discloses the return structure (rows with indicator key, displayName, signalKind, latest signal side, ts, error). This goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded. The first sentence states the core function, the second details the output structure, and the third covers constraints and failure behavior. Every sentence earns its place with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, idempotent tool with no output schema, the description covers the return format, the key behavioral constraints (max 20, fail-fast on unknown keys), and the interpretation guidance (LLM judges agreement). The only gap is the undocumented 'provider' parameter, which is optional and has an enum in the schema, so the agent can infer valid values. Overall, the description is nearly complete for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. The description explains the 'indicators' parameter implicitly by describing the table rows and the max 20 limit, and it mentions (symbol, resolution) as the shared context. However, it doesn't explain the 'provider' parameter at all, and the schema itself lacks descriptions for symbol, resolution, and provider. The description adds some meaning but leaves the provider parameter 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 states the tool runs N indicators in parallel against the same (symbol, resolution) and returns a compact confluence table. It distinguishes itself from siblings by emphasizing the parallel multi-indicator nature and the absence of a built-in voting rule, which is a key differentiator from get_indicator_signal.

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 when to use this tool: when you need confluence across multiple indicators. It explicitly states the LLM judges agreement from the table, which guides the agent on how to use the output. However, it doesn't explicitly name alternatives like get_indicator_signal for single-indicator queries, though the sibling list makes this inferable.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds 'read live from its registry,' a minor behavioral detail about the dynamic data source, but does not go beyond that. Given the comprehensive annotations, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each with a distinct purpose: stating what the tool does, describing the output format, and giving usage timing. No redundancy or filler, and the most important information is front-loaded.

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 listing tool with no parameters, no output schema, and comprehensive annotations, the description fully covers purpose, output fields, and usage guidance. An agent has all necessary information to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is trivially 100% and there is nothing to explain. The description correctly omits parameter details. The baseline of 4 for a no-parameter tool is appropriate, as the description adds no unnecessary filler.

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 catalogs every indicator the Sentimentracker backend can compute, read live from its registry, and specifies the exact return fields (key, displayName, signalKind, description). This unambiguous verb+resource pair distinguishes it from sibling tools that retrieve specific indicator data.

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 explicitly instructs to call this once at session start so the agent knows which key to ask about, providing clear timing and purpose. It doesn't explicitly name alternative tools or exclusions, but the 'once at session start' directive effectively frames it as a discovery step before using other 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to cover safety. It adds value by clarifying that the tool performs no IO, does not execute orders, and produces a payload for another tool, plus the follow-up tip about 'place_tpsl'. This is beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose and no-IO claim. Every sentence adds value: the destination, sizing modes, and follow-up tip. It could be slightly more structured but is not verbose.

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 is a pure compute with a rich schema and multiple enums, the description covers the key aspects: purpose, no IO, sizing modes, and the output flow. It doesn't explain return values, but there is no output schema and the tool hints it drops into another tool, which is sufficient. Minor gap: no mention of how signal is used beyond type, but schema covers that.

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 does name the three sizing modes (notionalUsd, fixedBase, riskUsd) and mentions optional takeProfitPx/stopLossPx, which adds meaning. However, it doesn't explain many other parameters like tif, orderType, limitOffsetBps, or the structure of signal envelope, though the schema is fairly descriptive for those.

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 'compose' and identifies the exact resource (a Hyperliquid 'propose_order' payload) and its destination. It clearly distinguishes this tool from signal-generation and indicator sibling tools by stating it is 'pure compute' with 'no IO', which is a unique purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states this tool is for composing a payload for a specific downstream tool, which implies when to use it (when preparing an order from a signal). It does not explicitly mention when not to use it or alternatives, but the strong 'no IO' and destination reference provide clear context and distinguish it from 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?

Annotations declare readOnlyHint, idempotentHint, and destructiveHint=false, which already indicate this is a safe read operation. The description adds significant behavioral context: it explains long-polling semantics, the timeout returning {signal: null, timedOut: true}, and the watermark condition. This goes beyond annotations, though it doesn't detail edge cases like network errors.

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 concise (three sentences) and front-loads the most critical information (long-poll, condition, timeout). Every sentence adds value: first states purpose, second explains behavior, third gives operational guidance. No fluff.

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's moderate complexity (7 params, nested config object) and no output schema, the description covers the essential usage loop and key parameters. It might benefit from explaining what a 'signal' contains, but the sibling get_indicator_signal likely defines that. Overall, sufficiently complete for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is very low (14%), so the description must compensate. It explains the critical parameter lastSeenSignalTs (the watermark) and timeoutMs (holds the call up to that time). However, it doesn't explicitly describe config, provider, or the exact format of signal, but those are secondary and possibly inferable from sibling context.

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's purpose: long-poll for a new signal on a specific (indicator, symbol, resolution). It explicitly mentions the timeout behavior and the condition (time > lastSeenSignalTs) for detecting a new signal, which is specific and distinguishes it from any simple fetch operation.

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 provides explicit usage guidance: it says to pair with get_indicator_signal to bootstrap lastSeenSignalTs, and it outlines the idiomatic agent loop (get → subscribe → react → update watermark → loop). This clearly tells the agent when to use this tool and how it fits with siblings, leaving no ambiguity.

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