Stelar Signals

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond that: results are computed from live 24h data (so they are time-sensitive, not static), produced by a production-grade classifier, and surface an extra grid_suitability verdict beyond the regime label. This enriches the agent's understanding of what the call returns and how fresh it is.

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

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

Three sentences, front-loaded with the core classification output, followed by the verdict and usage guidance. The only waste is that the asset list in the third sentence duplicates the schema enum, which is already fully specified; otherwise 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 output schema, the description must convey the return shape. It names the regime categories and the grid_suitability verdict, but leaves ambiguous whether the response returns both together, separately, or with additional fields like confidence or timestamp. For a 1-parameter tool with read-only annotations this is mostly adequate but has a clear gap around the exact 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?

Schema description coverage is 100% and the asset parameter is fully documented with an enum and description, so the baseline is 3. The description reinforces which assets are relevant by listing them in prose and explains the strategic context, but it does not add meaningfully new semantics about the parameter's format or interpretation beyond the schema.

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

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

The description names a specific output (market regime: chop/trend_up/trend_down/high_vol), the computation basis (live 24h market structure), and the assets covered. It is clearly not a generic or tautological statement. However, it does not differentiate itself from the sibling tool 'regime', whose purpose likely overlaps, so it misses the sibling-distinguishing criterion for 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?

Gives explicit when-to-use context: 'Use this before deciding to deploy a grid bot, mean-reversion strategy, or trend-follow strategy'. This is actionable and tied to a clear workflow. It does not mention when not to use it or name alternatives such as the sibling 'regime' tool, so it stops short of a 5.

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

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

Annotations already mark the tool as read-only and non-destructive, so the bar is lower. The description adds that scoring is 'via an LLM', which implies external AI processing and possible nondeterminism/cost, but provides no detail on rate limits or latency. This is adequate given the annotation coverage.

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, stating the output format and input modes before the use-case sentence. It is free of filler and every sentence contributes useful information, though the final use-case sentence is slightly promotional rather than strictly operational.

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

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

For a simple two-parameter read-only tool with no output schema, the description covers the return format (score range and label), both input modes, the supported asset list, and the exclusivity constraint. The main vagueness is what 'recent price action' means, but this is acceptable for a lightweight sentiment scorer.

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

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

Schema coverage is 100%, with both `text` and `asset` fully described and the asset enum documented. The description adds critical value by explicitly enforcing 'EXACTLY ONE of `text` or `asset`', a mutual-exclusion constraint not encoded in the schema since both are optional.

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 produces a sentiment score (-1 to +1) with a bullish/neutral/bearish label for either raw text or crypto asset price action. It identifies the verb, resource, and output format, but does not explicitly distinguish itself from the sibling `sentiment` tool, leaving some overlap 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 use cases (trading signals, news pipelines, social-listening) and the exactly-one-of-text/asset constraint, which implies appropriate usage. However, it never names alternative sibling tools or states when not to use this tool, so the when-to-use guidance remains implicit rather than explicit.

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 the tool read-only and safe. The description adds value by disclosing the LLM back-end and the fallback behavior for opinions or live-data claims ('Returns 'uncertain''). This exceeds what structured annotations convey, though it doesn't detail latency or reliability bounds.

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 tight and front-loaded: the core function and output are in the first sentence, followed by succinct use-case examples and an edge-case note. 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?

The tool is simple (one parameter, no output schema, read-only annotations). The description covers the return structure (verdict, confidence, reasoning) and a key edge case. It doesn't explicitly state the response format (e.g., JSON structure), but that's minor given the description already specifies the components.

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 fully describes the single 'claim' parameter (100% coverage), so the baseline is 3. The description adds a bit of context ('any factual claim') but does not elaborate on input format, constraints, or examples beyond what the schema already provides.

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

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

The description states a specific verb ('fact-check'), a resource ('any factual claim'), and the precise output shape (verdict, confidence score, reasoning). It clearly distinguishes itself from the crypto-focused sibling tools by its generic, LLM-based fact-checking scope.

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 explicit use cases ('content moderation, chatbot/agent guardrails, and misinformation screening'), providing clear context for when an agent should invoke it. It doesn't name alternatives or exclusions, but the tool's generic nature and the obvious contrast with crypto siblings make its intended role evident.

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 and destructiveHint=false, so the safety profile is covered. The description adds significant behavioral context beyond that: the call costs $0.05 USDC via x402, unpaid calls return payment terms instead of data, and the parameters are derived from live 24h market structure. This is exactly the kind of non-obvious behavior an agent needs to know.

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

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

Two sentences with no filler. The payment warning is placed first, which is the most critical operational detail, and the functional purpose follows immediately. Every word earns its place.

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

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

For a two-parameter tool with a required enum, the description and schema together cover the inputs. The return value is described at a high level (range, spacing, order size). It also explains the unpaid-call behavior, which is essential. There is no output schema, so a bit more detail about the exact payload shape could help, but it's adequate for correct invocation.

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

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

Schema coverage is 100%, so both `asset` and `capital` are already well-documented in the input schema. The description adds no further parameter-level detail; it only restates the concepts of 'pair' and 'capital amount.' Baseline 3 applies because the schema carries the semantic weight.

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 deliverable (recommended grid-trading parameters: range, spacing, order size), the input context (pair and capital amount), and the data source (live 24h market structure). This clearly distinguishes it from the sibling tools like price, sentiment, or regime, which address different concerns.

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 'Recommended grid-trading parameters for a pair and capital amount' implies the use case clearly. The context of grid trading is explicit, and the tool's purpose is distinct enough that an agent wouldn't confuse it with siblings. However, it doesn't explicitly mention when not to use it or name alternative 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 mark this as read-only and non-destructive, so the bar is lower. The description adds valuable behavioral context beyond the annotations: the exact cost per call, the payment mechanism (x402 on Base), and the fallback behavior for unpaid calls.

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 short sentences, with the critical paid-per-call warning front-loaded. Every sentence earns its place and there is no filler.

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

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

For a single-parameter, read-only snapshot tool, the description covers output content and payment behavior sufficiently, and no output schema exists to complicate expectations. It is slightly vague about what the 'simple signal' actually is, but this does not block 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 100% and the lone asset parameter is fully documented with an enum. The description adds no real semantic detail beyond what the schema already provides, so the baseline 3 is appropriate.

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

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

The description clearly states the tool returns current price, 24h/7d change, and a simple signal for a major crypto asset, so the core purpose is unmistakable. It does not explicitly differentiate this from the sibling pricecheck, but the resource and outputs are specific enough for an agent to understand what the tool does.

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 communicates that calls are paid and that unpaid calls return x402 payment terms, but it gives no guidance on when to choose this tool over siblings like pricecheck or crypto_regime. No exclusions, conditions, or alternative selection criteria are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds concrete behavioral detail by specifying the returned fields and the low-latency, snapshot-style nature of the lookup. It does not describe rate limits or signal methodology, but those are not critical for safe invocation.

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 concise sentences earn their place: the first front-loads the exact outputs, and the second adds the latency/use-case profile and allowed assets. No filler or redundant explanation beyond a useful quick reference list.

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 read-only lookup, the description covers the output shape, asset scope, and intended use. The main gaps are the unspecified quote currency and the criteria behind the bullish/bearish/neutral signal, but these are minor for a snapshot tool.

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 covers the single parameter completely with an enum and description. The description merely repeats the allowed asset list without adding extra meaning such as price quote currency or formatting, so it does not improve on the schema.

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

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

The description clearly specifies the tool's output: current price, 24h and 7d percentage change, and a bullish/bearish/neutral signal. It also defines the resource scope as a major crypto asset from an explicit allowed list, which distinguishes it from simpler price-only or sentiment-focused 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 gives clear intended usage contexts: low-latency lookups for dashboards, bots, and alerts. It does not explicitly name alternatives or state when not to use this tool, but the context is strong enough for an agent to infer appropriate selection.

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 indicate a safe read, and the description adds meaningful behavior beyond that: the $0.03 USDC x402 payment requirement and the fact that unpaid calls return payment terms instead of data. This is valuable context not present in the schema or 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 three tight sentences: payment warning first, then output definition and data basis, then unpaid-call behavior. No filler or redundant schema 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 single-parameter read-only classification call, the description covers the output categories, the computation basis, the cost, and the no-payment fallback. There is no output schema, but the semantic outputs are stated well enough to interpret the response.

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?

Asset is fully documented in the schema with an enum and description (100% coverage), so the description adds no parameter information. This matches the baseline for high schema coverage.

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

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

The description names a specific resource (market regime classification), lists the exact output categories (chop / trend_up / trend_down / high_vol), and adds a grid-suitability verdict, so an agent knows what the tool does. It does not differentiate from sibling crypto_regime, so not 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?

There is no guidance on when to choose this tool over crypto_regime or related risk/sentiment tools, and no exclusions or alternative routing. The only context is that it uses live 24h market structure, which is implied rather than stated as a usage condition.

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 the tool read-only and non-destructive. The description adds valuable behavioral context beyond annotations by disclosing the $0.02 per-call payment requirement and explaining that unpaid calls return the exact x402 payment terms. That is important pre-invocation information not present in the structured metadata.

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, front-loads the critical payment warning, and explains the output regime in one clear clause. The only minor flaw is redundancy between the title's payment note and the first sentence, but overall it is tight and scannable.

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

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

For a tool with a single parameter and no output schema, the description provides enough context to call it correctly: it names the input, specifies the output scale (low/med/high), defines the baseline window, and discloses payment behavior. It could include a concrete response example, but the simple domain makes that less critical.

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

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

Schema description coverage is 100% and the single asset parameter is already documented with an enum and field description. The description adds little beyond calling the asset 'major,' so the schema carries the semantic weight; a baseline score of 3 is appropriate.

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

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

The description clearly states that the tool returns a volatility/drawdown risk regime (low/med/high) relative to a 30-day baseline for a supported crypto asset. It is more specific than a tautology and the title reinforces the paid nature, but it does not explicitly differentiate itself from similarly named siblings like crypto_regime, regime, or token_risk.

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 sibling tools. It only explains payment behavior and the unpaid fallback, not the intended use case or conditions under which an agent should prefer this tool over alternatives.

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 and destructiveHint=false. The description adds valuable behavioral context beyond annotations: the per-call cost, the unpaid-call behavior, and the output shape (score plus label). No contradiction with annotations.

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

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

The description is extremely concise and front-loaded: it opens with the critical payment warning, then states the core semantics and unpaid behavior. Every sentence earns its place with no filler.

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

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

For a simple two-parameter read-only tool, the description covers the input constraint, the return format, and the payment gating. The schema and annotations cover the rest. It could be more complete by defining what labels look like, but nothing essential is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds an important semantic constraint not present in the schema: exactly one of text or asset must be supplied, not both and not neither. This meaningfully improves 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 clearly states the tool's function: produce a sentiment score (-1..+1) with a label for exactly one input of text or asset. It is specific about the resource and operation, though it does not explicitly differentiate itself from the sibling tool crypto_sentiment.

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

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

The description gives clear usage context: the call is paid, exactly one of text or asset must be provided, and unpaid calls return x402 payment terms. It does not mention alternatives or when not to use this tool, but the intended usage is unambiguous.

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 the tool is read-only and non-destructive. The description adds valuable behavioral context beyond annotations: it fetches a page when given a URL, summarizes raw text directly, produces a 3-5 sentence result, and requires exactly one input. This is strong disclosure for a simple read-only tool.

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

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

Two sentences with no filler. The output behavior is front-loaded, the parameter rule is explicit, and the use case earns its place. Every sentence conveys actionable 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 simple two-parameter, read-only tool with full schema coverage and no output schema, the description covers the input selection rule, the fetch-vs-direct behavior, the output format and length, and the intended use case. 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 schema already documents both parameters at 100% coverage, so the baseline is 3. The description adds the critical constraint that exactly one of `url` or `text` must be provided, which the schema does not enforce (zero required params, no oneOf). That meaningful addition pushes it above baseline.

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

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

The description states a specific verb ('summarize') with an explicit resource ('a URL or a raw text block') and adds concrete output detail ('tight 3-5 sentence summary, via an LLM'). It also clearly differentiates the two input modes, and the sibling tools are unrelated crypto/finance tools, so no confusion is possible.

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 clear context: use this when you need a fast, information-dense digest without making your own LLM call or web fetch. It does not explicitly name alternatives or when-not-to-use cases, but the sibling set is unrelated, so the guidance is sufficient for 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?

Annotations already mark the tool as read-only and non-destructive; the description adds valuable behavioral context by disclosing the $0.005/call payment requirement, the x402 mechanism, the lack of signup/API key, and the unpaid-call fallback. It does not cover rate limits or post-payment response details, but the key behaviors are transparent.

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

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

Two sentences with no filler: the critical payment caveat is front-loaded, and the second sentence packs the tool's purpose and unpaid-call behavior efficiently. The repetition of the title's cost is slightly redundant, but it adds specific USDC/Base and no-signup 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 zero-parameter read-only tool with no output schema, the description fully compensates by enumerating the telemetry categories and the payment edge case. An agent has enough to decide whether to call it and what it will retrieve.

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 empty with 100% description coverage, so no parameter documentation is needed. The description appropriately says nothing about parameters, matching the schema.

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

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

The description names the resource ('AI-managed long-horizon crypto portfolio') and the returned data categories: allocation, reconciled profit-and-loss, signal votes, and the human-approval trail. This clearly distinguishes it from price, risk, and sentiment siblings, though it lacks an explicit command verb like 'Get' or 'List'.

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 telemetry instead of siblings like risk, sentiment, or summarize. The paid nature is stated, but no use-case conditions, exclusions, or alternatives are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the output is categorical, focused on volatility/drawdown, and based on comparison to a 30-day baseline. It omits exact thresholds or classifier internals, but for a read-only indicator this is sufficient.

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 most useful information is front-loaded: output category, asset scope, use case, and baseline behavior appear early. The final sentence restating the asset enum is mildly redundant with the schema but does not significantly hurt readability.

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

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

For a single-parameter, read-only classifier with no output schema, the description is complete: it states the return scale, the asset set, the classification baseline, and the intended use. An agent has everything needed to select and invoke the tool correctly.

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

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

The only parameter, asset, is already fully documented in the schema with an enum and description, giving 100% schema coverage. The description's final sentence merely repeats that enum, adding no new parameter semantics.

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 it classifies volatility/drawdown risk regime for a major crypto asset, returning low/med/high, and gives the asset list. It references crypto_regime but does not sharply differentiate the two, so an agent may need extra inference to choose between them.

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

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

It explicitly names practical use cases—position sizing and stop-placement logic—and explains the output as volatility elevation relative to a 30-day baseline. It does not state when not to use it or exactly how it differs from crypto_regime or the generic risk sibling, but the context is clear enough for selection.

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