Mooncatcher Wire

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and freshness profile is largely covered. The description adds that this is the full site aggregate, but says nothing about pagination, whether limit truncates the board, or whether results are cached/snapshotted. With annotations carrying the safety burden, a 3 is appropriate.

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, front-loaded with the returned content before the site-equivalence note. Every clause carries information and there is no filler, though the second sentence is more flavor than operational 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?

With no output schema, the description is the only source of return-value information, and it does list the board's components (mood, counts, top stories, AI digest) rather than leaving the agent blind. It is still incomplete on the limit parameter and on the shape/format of the returned board.

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 single parameter (limit, default 20, min 1, max 60) has 0% schema description coverage and is never mentioned in the description. The agent gets no guidance on what limit controls (stories? counts? digest items?) or what happens at the 60 cap, so the description fails to compensate for the coverage gap.

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

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

States a specific resource (the Moon Catcher Wire board) and enumerates its contents: mood, counts, top stories by market impact, and the AI digest. That is far more than a tautology. It stops short of 5 because it never distinguishes this aggregate view from siblings like mcw-get-digest or mcw-list-stories, which cover overlapping content.

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 explicit when-to-use, when-not-to-use, or named alternative. 'This is what www.mooncatcherwire.com shows' implies it is the whole-site overview, but the agent must infer that this is the broad composite call versus the narrower mcw-get-digest / mcw-list-stories calls.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. Against that lower bar, the description adds real value by disclosing the return contents (split and highlights) in the absence of an output schema. It says nothing about staleness, caching, or what happens when no board is selected.

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

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

A single front-loaded sentence: purpose first, then the contents list. Every clause carries information and there is no filler or redundancy.

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 tool with rich annotations but no output schema, the description is close to complete — it tells the agent what the digest contains. It leaves minor gaps: no error/empty-state behavior or freshness indication.

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

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

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description's mention of 'the current board' is the only implicit input context, and it is handled adequately.

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

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

States a specific resource (the AI-written market digest for the current board) and enumerates its contents — overview, bull/neutral/bear split, per-ticker takeaways, clustered highlights — so an agent knows what it will receive. It does not explicitly differentiate itself from siblings like mcw-get-board or mcw-get-story, so it stops 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?

Usage is only implied: 'for the current board' signals the board-context prerequisite, but there is no explicit when-to-use, when-not-to-use, or named alternative among the sibling tools. An agent must infer this is the summary view rather than the raw board view.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds useful scope about what the payload contains (TSP review state, Moon Catcher Wire editor state 'if one has been set'), which hints at conditional/nullable fields, but says nothing about pagination, auth, or error behavior on a bad id.

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

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

A single front-loaded sentence with the resource and scope stated first and no filler. It is efficient, though the trailing clause about editor state is slightly compressed and could be clearer.

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?

There is no output schema, so the description should describe the returned shape; it gestures at the review/editor state fields but leaves the rest of the story payload and any failure modes unexplained. For a simple one-parameter read tool this is close to adequate, but not fully 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% for the single required 'id' parameter, so the description must carry the meaning; 'by its id' does confirm it is the story identifier, but adds no format, source, or lookup guidance (e.g., where the id comes from). Adequate but thin given the coverage gap.

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 verb+resource ('One story in full by its id') and clarifies the retrieval is a single full record rather than a list, which implicitly separates it from mcw-list-stories and mcw-search. It stops short of naming those siblings explicitly, so an agent must infer the routing.

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 'by its id' — use this when you already have a story id and need the whole record. There is no explicit statement of when to prefer this over mcw-list-stories or mcw-search, nor any prerequisite or exclusion 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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false, destructiveHint=false), so the bar is lower. The description adds genuinely useful domain context: `topic` reflects Moon Catcher Wire's own keyword rules rather than TSP's model, which an agent could not infer from structured fields. It says nothing about result size, ordering, or the `limit` default, so it stops short of rich behavioral disclosure.

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 front-loaded with the core purpose and then walks the filters in the same order as the schema, one clause each, with no filler. Every sentence conveys filter semantics.

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 list tool whose annotations already carry the safety profile, the description covers the filters adequately. However, with no output schema it could state what a story record contains or how `limit`/ordering behaves, and that gap keeps it at minimum-viable-plus rather than 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 only 40%, so the description must carry weight, and it does: it explains that `ticker` matches TSP ticker tags, `topic` matches MCW topic rules (with a pointer to mcw-list-topics), `since_hours` bounds by publication time, and `breaking_only` keeps high-impact wires. Only `limit` is left undocumented, which is the reason it is not a 5.

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 clear verb+resource ("Stories with filters") and enumerates the filter dimensions, so an agent knows this returns a filtered story list. It distinguishes its `topic` model from TSP's and points to mcw-list-topics, but it never explicitly separates itself from mcw-search or mcw-get-story, so sibling differentiation is partial.

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 when-to-use or when-not-to-use guidance, and no comparison against mcw-search or mcw-get-story. The mcw-list-topics reference is a cross-link for discovering topic slugs, not a routing alternative.

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 useful context that these topics are custom keyword rules over headlines and summaries rather than upstream ticker classifications, but it does not describe return format or pagination.

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 sentences and front-loads the topic resource before explaining the custom classification context. It is concise, though the phrase 'These are ours' is slightly opaque and could be clearer.

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 list tool with no output schema, the description explains what topics are but does not describe what the response contains or how topics and rules are structured. It is adequate but leaves the output shape unstated.

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 description baseline is 4. The description does not need to explain parameter semantics because there are no inputs.

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 Moon Catcher Wire topics and their rules, but it never states the action explicitly (e.g. 'list' or 'return'), relying on the tool name and title to carry that meaning. It does distinguish these topics from upstream TSP ticker classification, but the purpose remains somewhat vague without a clear 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?

No when-to-use or when-not-to-use guidance is provided. The description explains what topics are conceptually but never says when an agent should call this tool versus siblings like mcw-search or mcw-list-stories.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real behavioral value beyond them: case-insensitive matching and the special equality-match rule where a query equal to a ticker tag returns all stories with that tag. It omits how the default result limit of 20 and the max of 60 behave in practice.

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

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

Two tight sentences with zero filler; the core matching behavior is front-loaded and the special ticker-tag rule follows immediately.

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, annotation-covered read tool with no output schema, the description covers the essential matching semantics an agent needs. The only material gap is the 'limit' parameter's default and maximum, which are visible in the schema but 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It explains the query semantics well (what is matched, ticker-tag equality behavior) but says nothing about the 'limit' parameter, its default of 20, or its 60-result cap, leaving half the parameters undocumented in both places.

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

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

States a specific verb (search) and resource (headlines and summaries) scoped to 'the current board', so the agent knows exactly what corpus is queried. It never names a sibling such as mcw-list-stories or mcw-get-story, so differentiation from them is left to inference 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?

Usage is implied by 'search' and the ticker-tag shortcut, which hints at a valid lookup pattern. There is no explicit when-to-use/when-not statement and no routing to alternatives like mcw-list-stories for browsing the board.

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?

Beyond the annotations, the description discloses important data-freshness behavior: cadence_check timing, partial bar handling, live samples, built-series caveats, and low-timeframe level-only behavior. It is rich but dense, and some terms like FBB and TSP remain undefined.

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 purpose is front-loaded, but the description becomes a dense wall of technical caveats with nested parentheticals and repeated timestamps/flags. It contains useful detail, but structure and brevity are weak for a two-parameter 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?

Because there is no output schema, the description carries the return-value burden and does so extensively: analysis metadata, candles, levels, bars default/max, partial flags, live samples, and freshness fields. It is nearly complete, though some terminology and field-shape clarity could be improved.

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 bars, while the description adds meaningful semantics for timeframe such as which timeframes have bars versus levels only. However, it refers to `granularity` rather than the actual `timeframe` parameter and the schema has no timeframe description, leaving some mismatch.

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 resource: one timeframe's analysis, OHLCV candles, and support/resistance/FBB levels, with Bitcoin-only and beta scope. It distinguishes the asset scope but does not name sibling tools or explicitly contrast with mcw-signals-market-data, mcw-signals-overview, etc.

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 does not say when to use this tool versus alternatives such as mcw-signals-market-data or mcw-signals-overview. Usage is only implied by the returned fields; there are no exclusions, prerequisites, or alternative-selection 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?

The description adds substantial behavioral context beyond the read-only annotations: default truncation to the newest 3 points per series, the `history` block reporting omitted points, pending ETF days having null flows rather than 0, `stopped_refreshing` timing rules, and clock verdicts being judged at answer time. These details materially help an agent interpret results and avoid misreading nulls or stale data.

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 dense, run-on wall of text with many embedded caveats and parentheticals. Although much of the detail is useful for a complex data tool, it is not scannable and could be structured into shorter sections or bullets. The opening sentence is front-loaded, but later sentences pack multiple concepts together.

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 carries the burden of explaining returns, defaults, null semantics, timing rules, and metric definitions. It does this thoroughly, including what `stats`, `flow.retail`, ETF flows, open interest fields, and clock verdicts mean, and how default history is truncated.

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 is only one parameter, `history`, and the schema already documents its boolean behavior. The description adds meaningful context: the default returns the latest complete reading plus the newest 3 back-history points, and the answer includes a `history` block showing how many older points were omitted. This goes beyond the schema's brief note about answer size.

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 this tool returns BTC derivatives market data and enumerates the included metrics: funding, open interest, liquidations, long/short, taker volume, ETF flows, options max pain, and fear/greed. It also distinguishes two sibling tools by saying sentiment data lives in mcw-signals-sentiment and price-feed verdicts in mcw-signals-meta. It does not explicitly differentiate itself from siblings like mcw-signals-overview or mcw-signals-charts.

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 mostly implied through the metric list and the note that sentiment and meta data live in sibling tools. The description does not say when to choose this tool over mcw-signals-overview, mcw-signals-charts, or mcw-signals-thesis. It does give clear guidance on the `history` flag, but not on tool-level 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-structured behavior: the tool is 'Bitcoin only, beta,' the snapshot can be 'degraded' with a reason, sources may be 'carried from an earlier run,' and each source carries its own observed time — all of which shape how an agent should interpret the result. It stops short of stating return format or how staleness thresholds are computed.

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 purpose and the Bitcoin/beta constraint are front-loaded, and the later sentences, while dense with field names and backtick references, each carry distinct information about the response. It reads as one long paragraph with a somewhat sprawling final sentence on the TSP-vs-Wire verdicts, so structure could be tighter, but there is little true 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?

With no output schema and no parameters, the description carries the full burden of explaining what comes back, and it does so thoroughly: timing, age, degradation, per-source provenance, the two competing freshness verdicts, and the beta/not-advice notice. An agent has enough to decide whether to call it and how to read the result.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description instead spends its budget on the shape of the returned fields (feed_freshness, tsp_status, verdict_at, wire_check, verdicts_differ), which is the right allocation here.

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 specific resource (the BTC signals snapshot) and enumerates exactly what it reports: snapshot time, age of newest value, degradation state and reason, per-source observed times, carried-forward flags, and the beta/not-advice notice. It explicitly distinguishes itself from siblings — 'the only one of the signals tools that is purely about the age of the data' — so an agent can separate it from mcw-signals-overview, -market-data, -thesis, etc. without opening a schema.

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 selector condition: this is the signals tool to reach for when the question is data freshness rather than content, and it clarifies that tsp_status and wire_check are two independent verdicts where 'neither replaces the other.' That is useful routing context, but there is no explicit when-not or a named alternative for related questions (e.g. where to go for values rather than age).

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?

Beyond the annotations, the description adds substantial behavioral context: it flags the tool as beta, states that only direction and confidence are published (no entry/target/stop), explains freshness and staleness semantics, describes cadence checks, and notes that `live` is null when nothing is stored. These details help an agent interpret the response without contradicting the read-only, idempotent 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 core purpose is front-loaded, but the description is a dense single paragraph packed with implementation-level thresholds and parentheticals. Much of the detail is relevant given the lack of an output schema, but the structure could be more scannable and less verbose for a no-parameter overview 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?

With no output schema, the description carries the burden of explaining return semantics and does so extensively, including `spot.delta_pct`, timeframe consensus, `live.timeframes`, `freshness`, `judged_on[].cadence_check`, and staleness rules. It gives an agent enough context to understand what the response represents and how to interpret recency and limitations.

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

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

The tool takes zero parameters, so there is no parameter semantics to clarify and the baseline is 4. The description does not need to compensate for missing schema coverage because the schema is empty and fully described by the absence of parameters.

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 resource and scope: a Bitcoin-only signals overview covering spot price/change, timeframe trend/direction/confidence, consensus, bull/base/bear cases, and support/resistance. It does not explicitly distinguish this tool from most siblings such as mcw-signals-charts or mcw-signals-market-data, though it cross-references mcw-signals-thesis for label definitions.

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 only implied by the 'overview' framing and the listed contents; there is no explicit when-to-use or when-not-to-use guidance versus sibling signals tools. The cross-reference to mcw-signals-thesis clarifies where thesis labels are defined, but not when an agent should choose 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 a safe, idempotent, closed read, but the description goes well beyond them: null means 'no data, never 0', sub-threshold buckets are thin, an hour with no readings has no bucket, TSP rewrites a closed hour, out-of-range scores are published as null, and staleness is judged at answer time via cadence_check/age_s. This is unusually rich behavioral disclosure for a read 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?

The critical scoping constraint is front-loaded and almost every clause conveys a field name or edge-case rule that an agent cannot get elsewhere (there is no output schema). It is dense, single-paragraph prose that would scan better with structure, but little is padding.

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 carry the full return-shape burden, and it does: each of the four series blocks is described with its fields and edge cases, plus defaults, history behavior, and freshness signals. An agent has everything needed to call and interpret it.

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% and the single param's own description already explains the newest-3 default and the caps. The prose reinforces this and adds a genuinely new detail beyond the schema: the answer's 'history' block reports how many older points were omitted. That extra meaning lifts it above the baseline 3.

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

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

States a specific resource and scope up front: 'TSP's sentiment readings for BTC' and 'Bitcoin only, beta'. It then enumerates exactly which series it returns (hourly, ema, news_index, blend), which lets an agent recognize the tool. It never names or contrasts a sibling (e.g. mcw-signals-overview), so it stops short of full differentiation.

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 explicit when-to-use or when-not-to-use guidance, and no alternative tool is named despite many sibling signals tools. The only conditional behavior given ('Set history to true for the full stored series') is parameter mechanics, not tool-selection 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?

Annotations already declare a safe read-only, idempotent operation, and the description adds substantial behavioral context: null semantics, tie-breaking behavior, staleness rules by input family, cadence checks, and the explicit absence of entry, target, stop, and reasoning text. It also states that outputs are direction and probability only, with a not-investment-advice caveat.

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 long and dense, but the length is justified because there is no output schema and many field-level semantics must be conveyed. Scope is front-loaded, though the field details could be easier to scan with more structure.

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

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

With no output schema and a rich, complex result shape, the description does an unusually thorough job of explaining the returned fields, horizon composition, staleness checks, null cases, and explicit exclusions. An agent has enough information to interpret the response 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?

There are no input parameters to document, so the baseline is 4. The description correctly focuses on output and behavioral semantics instead of inventing parameter details.

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 and scope: Bitcoin-only bull/base/bear thesis cases across three horizons, as shown in the Signals page's Thesis tab. This clearly distinguishes it from sibling signal tabs such as charts, market data, overview, and 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?

It clearly establishes the usage context and constraints: Bitcoin only, beta, three horizons, and the Thesis tab. It does not explicitly name alternative tools or say when not to use this one, but the context is sufficiently clear for a zero-parameter read endpoint.

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