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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. Beyond that the description discloses genuinely non-obvious behavior: the partial-bar flag semantics, live sampling with null ingested_at, how built series inherit the 1h bar's health/freshness, and that built series' high/low span the underlying 1h bars. Auth and rate-limit behavior are not covered, but the disclosure is well above the annotation baseline.

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?

Front-loaded with 'Bitcoin only, beta' and the core content, which is good. But the remainder is roughly 300 words of dense, heavily parenthetical prose with run-on sentences for a two-parameter read-only tool; the partial/live/built-series edge cases could be structured far more legibly. Size is defensible for the semantics but the structure is not.

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?

No output schema exists, so the description carries the full burden of explaining returns, and it does so in depth: bars count, bar attributes, the partial and live flags, and built-series behavior. It stops short of explaining 'FBB' and exact response shape, but an agent has enough to interpret results 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 coverage is 50% – bars is documented in the schema and the description merely repeats its default/max. The timeframe parameter has no schema description, and the description compensates substantially by explaining that 2H/6H/8H/12H are built from 1h bars while 1m/3m/5m/15m carry levels only and no bars, which is semantic information an enum list alone cannot convey.

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 opening sentence states a specific resource: one timeframe's analysis plus its OHLCV candles and the support/resistance/FBB band levels it lists. An agent knows exactly what data comes back. However, it never distinguishes itself from the nearby sibling mcw-signals-market-data, which plausibly also serves price series, so routing still requires inference.

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 guidance against the eleven siblings, some of which (market-data, overview, thesis) overlap conceptually. The conditional phrasing about granularity ('note says so') explains how to read results, not when to select this tool. 'Levels, not a trade plan. Not investment advice.' is a disclaimer, not usage guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: default truncation of back-history to the newest 3 points per series with a `history` block reporting how many were omitted, `history=true` roughly doubling answer size, null-not-zero semantics for pending ETF days, null for unshown venues, `newest_partial`/`newest_bar_open` meaning, and that clock verdicts are judged at answer time. That is unusually rich behavioral context 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?

It is one dense wall of prose with heavily nested parentheticals and no headings or bullets, which makes a genuinely intricate payload harder to parse than necessary. Some of the field-level vocabulary is justified given no output schema, but the most decision-relevant facts (default history truncation, sibling routing) are buried at the end rather than front-loaded, and other sentences could be tightened without loss.

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, one optional parameter, and a very wide payload, the description accepts the burden of defining each field's semantics, null behavior, cadence and timing. It is close to complete for correct interpretation, though it says nothing about error/failure behavior or what 'beta' implies for stability.

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% on the single `history` boolean, so the baseline is 3. The description still adds meaning the schema lacks: the default back-history is the newest 3 points per series, the full stored series is returned when true, and the response carries a `history` block reporting omitted points. That is real value beyond the property's own description.

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 first two sentences name a concrete resource domain — the BTC derivatives market — and enumerate exactly which metrics are covered (funding, OI, liquidations, long/short, taker volume, ETF flows, max pain, fear/greed), and it explicitly points sentiment to mcw-signals-sentiment and feed verdicts to mcw-signals-meta. The only weakness is that there is no crisp declarative verb — the purpose is conveyed as a field catalogue rather than 'returns X', and the statement of what is actually returned (latest reading of every metric, 3 back-history points) is deferred to the very end.

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 routes the agent to alternatives for adjacent data ('TSP's sentiment readings are in mcw-signals-sentiment, and its verdict on each price feed in mcw-signals-meta') and tells when to flip `history` ('Set `history` to true for the full stored series'). It gives clear context but no exclusion conditions and does not distinguish itself from mcw-signals-charts or mcw-signals-overview, which likely overlap.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: it discloses that every value carries its own observed time, what `freshness` means, that inputs are judged per series cadence (judged_on[].cadence_check, per-family staleness, ETF flows by two days), and the honest limitation that TSP does not state the delta_pct period. It also flags 'beta' status and that no trade levels are published.

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?

It is front-loaded with the scope ('Bitcoin only, beta') but then unspools into a single very long run-on sentence dense with nested parentheticals, making it hard to parse. Nearly every clause carries information, but the structure does not help an agent scan it quickly.

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 must carry the full burden of explaining what comes back, and it largely does: enumerated content, freshness/staleness semantics, label ownership, and caveats. It is slightly short of complete because the exact shape and keys of the returned structure are only partially enumerated.

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 the baseline is 4. The description nonetheless explains return-field semantics such as `spot.delta_pct` being in percent, `most_probable_arm`/`dominant_case`, and `judged_on[].cadence_check`, which adds meaning even though no input parameters exist to clarify.

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 enumerates its content precisely: BTC spot price with delta_pct, trend/direction/confidence across thirteen timeframes with consensus, bull/base/bear cases with probabilities for three horizons, and recurring support/resistance. It also fixes scope ('Bitcoin only') and explicitly defers thesis labels to mcw-signals-thesis, so an agent can place it against siblings such as mcw-signals-market-data and 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?

There is no statement of when to choose this tool over mcw-signals-charts, mcw-signals-market-data, mcw-signals-sentiment or mcw-signals-thesis. The only routing hint is that thesis labels are defined in mcw-signals-thesis, which is a definition pointer rather than usage guidance, and the content exclusions ('no entry, target or stop is published') describe data scope, not when to call this.

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/closed-world, yet the description adds substantial behavioral context on top: null means no data (never 0), thin buckets below `thin_below`, hours with no readings produce no bucket, TSP rewrites a closed hour, `newest_bucket_open` reports liveness, and per-block `cadence_check`/`age_s`/`stale` are judged at answer time. This is unusually rich disclosure well 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 first sentence front-loads scope, but the body is a single dense wall of prose with heavy nested clauses (semicolons, em-dashes, stylized quotes) that is hard to scan. Most sentences carry real information for a no-output-schema tool, but the volume and lack of structural grouping (per-series lists) work against 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?

With no output schema, the description must describe returns, and it does so exhaustively per series (field names like `mean_sentiment`, `stddev_sentiment`, `computed_at`, `weighted_sentiment`, `confidence`, `article_count`) plus staleness and null semantics. Nothing an agent needs to interpret the response 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 coverage is 100% for the single `history` parameter, so the baseline is 3. The description adds value beyond the schema by explaining the interaction with the response's `history` block and the per-series caps (48 hourly buckets, 24 EMA points, 30 days news), clarifying the consequence of the flag.

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 the resource precisely: TSP sentiment readings for BTC, broken into four named series (hourly, ema, news_index, blend) with field-level detail. It scopes the tool ('Bitcoin only, beta'). It never names or contrasts a sibling (e.g. mcw-signals-market-data, mcw-signals-charts), so an agent gets a clear picture of the tool but no explicit disambiguation.

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

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

Usage is implied by the content (retrieve sentiment readings), and the `history` toggle has an explicit default-vs-full-series rule. But there is no when-to-use/when-not guidance and no comparison to the other mcw-signals-* siblings, so an agent must infer 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 cover readOnly/idempotent/destructive=false, and the description adds substantial behavioral context beyond them: null semantics for unknown cases, `probabilities_tie` behavior, per-input staleness rules (ETF flows stale by two days since row write), cadence checks at answer time, and an explicit statement of what is NOT published (no entry, target, stop, or reasoning text).

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?

Purpose is front-loaded in the first sentence, but the body is a dense run-on paragraph mixing field definitions, null rules, and timing caveats without structural breaks. Because no output schema exists, the field detail does earn its place, but readability suffers.

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 zero parameters, the description carries the full burden of documenting returns, and it does so comprehensively: horizons, per-case fields, aggregate confidence, tie-break logic, input freshness rules, timeframe provenance, and explicit disclaimers about unpublished data.

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 for the description to disambiguate; the baseline of 4 applies. Its extensive field-level prose documents the return shape rather than arguments.

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 the resource (thesis: bull/base/bear cases across scalp, short and long horizons) and scope (Bitcoin only, beta) with a specific verb-like framing. It ties itself to 'the Signals page's Thesis tab,' which implicitly distinguishes it from the other Signals siblings (charts, market data, sentiment, overview, meta), but never names them 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?

The description explains what the data contains but not when to choose this tool over siblings like mcw-signals-overview or mcw-signals-sentiment. No when-to-use, when-not-to-use, or alternative-tool guidance is given; the tab reference is contextual framing, not usage direction.

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