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

Annotations already declare readOnlyHint, idempotentHint and closed-world behavior, so safety is covered. The description adds genuinely non-schema information: the call is metered at $0.01 USDC per invocation via x402, which is a cost signal an agent needs before calling. It does not state rate limits or failure modes, but for a zero-argument read that is a minor 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?

Three compact sentences with no filler: what it returns, when to use it, and what it costs. The field list is front-loaded and the usage cue and pricing follow in a logical order.

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 correctly compensates by enumerating the returned fields, and with no parameters the input side is trivially covered. Remaining ambiguity is minor but real: units/semantics of 'exposure' and '30-day volatility', and the granularity of 'daily', are left undefined.

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, so the baseline is 4. The description nonetheless explains the implicit input: the basket is fixed to BTC + ETH by default, which tells the agent it cannot scope the request and must look elsewhere for other assets.

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 specific verb+resource ('combined daily trend signal') and pins the scope to a concrete default basket (BTC + ETH), then enumerates the returned fields (signal LONG/FLAT, exposure, SMA50, 30-day volatility, close, dates). It implicitly separates itself from siblings like get_trend/get_regime via 'combined' and 'overall market stance', though it never names those siblings explicitly.

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

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

'Use when you need the overall market stance' supplies a clear selection cue for this no-parameter call. It stops short of explicit when-not guidance or naming get_trend/get_regime/get_indicators as the alternatives an agent should pick when it wants single-asset or indicator-level data.

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