GW8 Signal API

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

With no annotations, the description carries the full burden and does so well: it discloses rate limits (2000 calls, 60/min), a one-time token reveal, the exact price and chain ($1.00 USDC on Base), the in-band x402 payment flow with the _meta key, and an HTTP fallback endpoint. These are exactly the operational facts an agent needs for a paid, non-reversible purchase.

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 and every clause carries real information (token usage, rate limit, exclusions, price, payment mechanism, fallback URL). It is a single dense mega-clause structure rather than cleanly separated sentences, which slightly hurts scannability, but there is little true waste.

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

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

Given zero parameters, no annotations, and no output schema, the description still covers payment, pricing, rate limits, token handling, exclusions, and an alternate HTTP route. Nothing an agent needs to invoke this correctly appears to be 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?

There are no input parameters, so the baseline is 4. The description still adds value by defining the output contract (the returned token) and how to present it downstream, but there is no input schema 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 verb+resource ("Buy a 24h pass for every paid GW8 data tool/endpoint") and immediately distinguishes itself from the get_* siblings by scoping to paid endpoints. An agent can tell this is the purchase action versus the read/inspection tools without opening the 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?

Explains how to use the artifact it returns (pass argument / X-GW8-Pass header) and gives a clear exclusion ("Excludes alert subscriptions"), which routes the agent away from this tool for alert needs. It does not, however, explicitly point to subscribe_green_dot_alerts or list_paid_endpoints as the alternatives, so guidance is strong but not complete.

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?

No annotations are present, so the description carries the full behavioral burden, and it does disclose real invocation-critical context: the $0.01 USDC-on-Base cost, in-band x402 MCP payment via the _meta 'x402/payment' field, and an alternate REST endpoint. It stops short of describing output shape, freshness, or failure modes, which a paid data tool would ideally cover.

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: identity first, then cost/payment, then the HTTP fallback. Front-loaded and largely free of padding, though the payment mechanics are dense with identifiers that could be shortened.

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 should hint at the return shape of this niche indicator, and it does not. Payment and endpoint details are complete, but an agent still cannot anticipate the response structure or cadence.

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 'pass' parameter is fully documented in the schema, including its link to buy_day_pass. The description never mentions the pass option, so it adds no meaning beyond the schema; baseline 3 applies.

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 (WaveTrend band dots) and a precise scope (66 Kraken 4h USD pairs), so the agent knows exactly what data comes back. It does not differentiate itself from adjacent signal tools like get_full_signal or get_regime, and 'band dots' remains somewhat niche jargon, but the resource is concrete.

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 call this instead of get_full_signal, get_regime, or the other signal siblings, nor any stated preconditions beyond payment. The agent is left to infer the use case from the description alone.

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?

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: the response is deliberately truncated ('top 3 dots (symbol+band only)') and the hit-rate is 'simulated', which warns the agent the metric is not a real backtest. It does not cover auth, rate limits, or freshness/latency guarantees.

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 lists the payload, followed by one short upsell sentence with prices that earns its place by routing the agent to paid alternatives. No filler or restatement of the name.

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 annotations, the description must explain the return shape, and it does by naming the included fields. It is adequate for a zero-parameter read tool, though it omits rate limits and how the simulated metric should be interpreted.

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 and the schema is empty at 100% coverage, so the baseline of 4 applies. There is no parameter surface for the description 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 verb+resource ('Free partial live brief') and enumerates the exact fields returned: regime score, green/red counts, top 3 dots, simulated 7d hit-rate. It also flags the resource as a truncated preview ('partial', 'symbol+band only'). It does not name sibling tools like get_daily_brief or get_band_dots, referring to paid endpoints by API path instead, so it stops short of full sibling 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?

The word 'Free' plus the upsell list implies this is the no-cost entry point and that fuller data lives behind /api/brief, /api/dots, /api/agent. That is an implicit when-to-use signal, but there is no explicit statement of when to prefer this over the sibling tools such as get_daily_brief or get_band_dots, nor any 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?

With no annotations, the description carries the full burden and does disclose the most consequential trait: this call is paid ($0.005 USDC on Base, settled in-band via x402 and the _meta 'x402/payment' field). It also names a free-ish HTTP fallback endpoint and, via the schema, a day-pass bypass. It still omits cache freshness/lag, failure behavior, and what the snapshot contains, so it is not complete.

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 what the tool returns, then the payment/access mechanics. The dense parenthetical about x402 is compact given how much commercial detail it conveys.

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 is the only source for return content, and it says only 'WaveTrend 4h snapshot' without listing the values returned. It does cover access/payment adequately, but an agent still lacks parameter semantics and output shape for a 2-parameter 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?

Schema description coverage is 50% – the 'pass' parameter is documented in the schema but 'symbol' carries only an enum with no per-value meaning, and the description adds nothing about either parameter. With coverage this low the description should compensate, and it does not.

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 indicator (WaveTrend), timeframe (4h), and scope (one coin), which is enough to distinguish it from nothing-else in the list. It does not, however, distinguish itself from close siblings like get_full_signal or get_band_dots, which also appear to be per-coin signal reads.

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 pick this over get_full_signal, get_history, or get_band_dots, nor prerequisites beyond the implicit single-symbol scope. The agent must infer that this is the narrow per-coin WaveTrend read.

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?

With no annotations, the description carries the full burden and does well: it discloses per-source labeling (ok/unavailable), no stale fill, the paid in-band x402 payment model ($0.02 USDC on Base), and an alternate HTTP endpoint. It omits rate limits, auth beyond payment, and error behavior, so it stops short of 5.

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 the resource and scope, then packed with useful detail (fields, labeling, payment, alternate endpoint). Dense single block with some run-on phrasing, but nearly every clause 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?

No output schema exists, yet the description enumerates the returned document fields and source-status semantics, and covers the payment/pass mechanics. Complete enough to invoke correctly; only edge-case behavior (empty results, partial failures) is unaddressed.

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?

One optional parameter with 100% schema description coverage, so the schema already documents the day-pass token fully. The description adds no syntax or semantics for 'pass', though it does explain the x402 payment context that the token bypasses.

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+resource: CFTC/SEC crypto rulemaking from the last 90 days, enumerating doc types (ANPRM/NPRM/final/notice) and fields (RIN, comment deadline, stage-change flag). This clearly separates it from siblings like get_gov_contracts and get_rwa_feed.

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 scope (regulatory rulemaking feed), but there is no explicit when-to-use, when-not, or named alternative among siblings. The payment note tells the agent the cost but not when this tool is the right pick over the other feed 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?

With no annotations, the description carries the full burden and delivers real behavioral detail: once-per-day cadence, $0.02 USDC on Base, in-band payment via x402 MCP referenced in _meta "x402/payment". It does not cover payment-failure behavior or what the paid call returns on error, keeping it short of a 5.

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, front-loaded with the tool's purpose and contents, followed by the essential payment and alternate-access facts. 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?

No output schema and no annotations, so the description must stand alone — it compensates by listing the brief's contents and the payment mechanics. Only the return shape/format and error behavior are unaddressed.

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% (the single optional 'pass' param is fully documented in the schema as a GW8 day pass that skips per-call payment), so the baseline of 3 applies. The description adds nothing about the parameter.

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 and resource (once-per-day brief) and enumerates its contents — regime, dot counts, top 10 coins by dot strength, BTC/ETH/SOL flows — so the agent knows exactly what it returns. It does not explicitly name which siblings (get_regime, get_flows, get_band_dots) it supersedes, so sibling differentiation is only implicit.

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?

Mentions an alternate access path (GET .../api/brief) and the payment cost, implying usage context, but gives no explicit guidance on when to choose this aggregate brief over the individual regime/flow/dot tools. Usage is inferable rather than stated.

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?

No annotations, so the description carries full burden. It does usefully disclose a paid call ($0.02 USDC on Base, x402 in-band payment) and the data provenance (Kraken, single venue, not on-chain), but says nothing about failure behavior, payment refunds, rate limits, or what the response contains.

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 dense sentences plus a URL, with the core data description front-loaded ahead of the payment and endpoint details. No filler, though the pricing/endpoint sentence is packed tightly.

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 annotations, the description must carry more weight. It adequately conveys what data the tool returns and that it costs money, but omits return format, error behavior, and clear differentiation from the dot-related sibling.

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% and the schema already documents the optional 'pass' param and enumerates 'symbol'. The description adds little beyond reinforcing the symbol as a path parameter via the REST URL; it does not explain the pass token's semantics further.

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 data product: a Kraken large-print buy/sell summary joined with WaveTrend 4h state, with a clear scope note ('single venue, not on-chain'). It does not explicitly route against siblings, though none of the listed siblings appear to overlap on this exact dataset.

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 call this versus alternatives like get_band_dots, get_full_signal, or get_coin, despite overlap implied by the 'dot state' in the title. Payment mechanics are described, but no usage context or prerequisites for choosing this tool.

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?

With no annotations, the description carries the full behavioral burden, and it does disclose the critical trait: cost of $0.02 USDC on Base paid in-band via x402 MCP, plus a raw POST endpoint. That payment disclosure is genuinely valuable and non-obvious. However it omits rate limits, whether the data is real-time or delayed, caching behavior, and the read-only nature, so it is not fully 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 dense sentences with no filler, and the data composition is front-loaded ahead of the payment logistics. The payment/pricing sentence is information-heavy but each element (price, chain, protocol, alternate endpoint) is relevant. Minor deduction for cramming four distinct facts into one run-on clause.

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 paid, unannotated tool with no output schema, the description covers what data is returned and how payment works, which are the essentials. It still leaves gaps an agent would want: response format, freshness of the signal, and how it relates to the component siblings. Adequate but not 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 100% and the single 'pass' parameter is fully documented in the schema as a GW8 day pass that skips per-call payment. The description alludes to the payment-skipping path but never references the parameter by name, so it adds no meaning beyond the schema. Baseline 3 applies.

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 data composition — Stage 1 regime score, WaveTrend 10/21/4, 66 Kraken 4h pairs, band dots — which implicitly distinguishes it from siblings like get_regime and get_band_dots that return those components individually. There is no explicit verb, but for a data-fetch tool the resource is unambiguous. It falls short of 5 only because it never explicitly contrasts itself with the 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?

There is no statement of when to use this composite signal versus get_regime, get_band_dots, or get_sample. The only usage-adjacent content is the payment path, which is a logistics note rather than selection guidance. An agent must infer the use case from the data composition alone.

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?

With no annotations, the description carries the full burden and delivers: data source and 14-day window, an explicit blocked-source disclosure (dodAnnouncements=unavailable) with a ~90-day DoD lag, and the payment requirement ($0.01 USDC on Base via x402, or a pass token). These are exactly the behavioral traits an agent needs before invoking.

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-loads the resource and scope, then filters, then the source caveat and payment note. Dense but mostly earning its place; the trailing RAW URL is arguably redundant with the tool binding itself.

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, yet the description enumerates returned fields, states the payment/auth path, and flags the data-freshness limitation. For a 4-param, zero-required read feed, nothing an agent needs to call it correctly 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 only 25% (only 'pass' documented), so the description should compensate. It labels the filters as optional but adds no semantics beyond the schema: what 'q' matches, what each sector enum value denotes, or the ticker format (only a pattern in the schema). Marginal value over structured fields.

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 and resource ('Recent (14-day) US federal contract actions') with precise coverage: sector list, source (USAspending.gov), and returned fields (tickers, amount, agency, date, description, award link). No sibling overlaps in the feed line, so the agent can distinguish it immediately.

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?

Names the optional filters (ticker / sector / q) and gives context for the DoD source gap plus a status-check endpoint. However, it does not explicitly say when to prefer this feed over a sibling or what would steer an agent elsewhere; guidance is clear but not exclusionary.

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?

With no annotations, the description carries the full burden. It usefully discloses the payment model ($0.05 USDC on Base, x402 MCP, _meta 'x402/payment') and the HTTP alternative, which are genuine behavioral facts. However, it never says what the response actually contains structurally, nor any rate limits, so real behavioral gaps remain.

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 a single dense sentence-plus-clause block that front-loads what the tool delivers before the payment logistics. Content is efficiently packed with little waste, though the payment/URL tail makes it slightly busy.

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 2-param paid fetch tool with no output schema, the description covers payment/auth and the green/red semantics but omits the shape of the returned backtest and any guidance on choosing it over get_band_dots. It is adequate but has clear holes an agent would want filled.

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%: the optional 'pass' token is documented in the schema, but the 'pair' enum has no description in either place. The description adds no parameter-level meaning (no syntax, no note on what pairs drive, no relation to the 90-day window), so it 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?

The description states a concrete verb and resource: a rolling 90-day band-dot backtest with forward moves and live hit rates, plus the meaning of the green/red dots. This lets an agent separate it from get_band_dots (current dots) reasonably well, though the sibling routing is left implicit rather than named.

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 guidance. The description never says to prefer this over get_band_dots for historical performance, nor what conditions select it. The only conditional context is the payment path, not tool 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?

With no annotations, the description carries the full burden and does disclose the critical behavioral trait: this is a paid call ($0.02 USDC on Base, in-band via x402 MCP, _meta "x402/payment") with a pass-token bypass. It omits rate limits and failure behavior, but the payment/auth context is unusually well covered.

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 the returned data fields, then payment details and the alternate endpoint. Dense but every clause is informative; the long field enumeration earns its place given no output schema exists.

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 annotations, the description does the heavy lifting by listing return contents and the payment flow. It is essentially complete for a single-optional-param fetch tool, missing only rate-limit/error context.

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 'pass' parameter is fully documented in the schema. The description alludes to the pass ('skips per-call payment') but adds no syntax or format detail beyond what the schema already provides, so baseline 3 applies.

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 (new Kraken USD pairs from the last 30 days) and enumerates exactly what is returned: first-seen date, price, 24h volume, % change since listing, WaveTrend 4h dot state, and blog posts. An agent can distinguish this from siblings like get_coin or get_band_dots 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 useful access mechanics – pay $0.02 per call or skip payment with a pass, and a raw HTTP GET alternative – but never states when to prefer this tool over sibling data feeds (e.g., get_coin, get_full_signal). Usage is implied by the payment note rather than explicitly framed.

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?

With no annotations, the description carries the full burden and does disclose important behavior: the call is paid ($0.01 USDC on Base), payment is in-band via x402 MCP with a _meta 'x402/payment' field, and a day pass can bypass it. It does not describe the return shape or any rate limits, but cost/auth disclosure is genuinely valuable context not present in structured fields.

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 the purpose in the first clause, followed by payment and endpoint details. It is short and mostly earns its place, though the raw URL and package name are somewhat operational noise for an agent that uses the MCP 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?

For a paid data-retrieval tool with no output schema and no annotations, the description covers the payment path well but says nothing about what the returned regime values look like or how to interpret 'raw values and rules'. Adequate but with a clear gap in output expectations.

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 optional 'pass' parameter is fully documented in the schema, including its source and that it skips per-call payment. The description adds no parameter syntax or format detail beyond that, so the baseline 3 applies.

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 concrete verb+resource: it performs a 'crypto regime check' and returns 'raw values and rules'. However, 'Stage 1' is unexplained jargon and the description does nothing to distinguish it from siblings like get_full_signal or get_band_dots, so it clears the bar for clarity but not 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?

No when-to-use guidance is given: it never says when an agent should call get_regime versus get_full_signal, get_band_dots, or get_daily_brief, nor what preconditions apply. The only routing information is the alternate HTTP endpoint and payment mechanics, which is access info rather than 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?

With no annotations, the description carries the full burden and does disclose the key behavioral trait an agent must know: this is a paid call ($0.02 USDC on Base, x402 in-band via _meta 'x402/payment'), with the day-pass escape hatch documented. It omits freshness/caching cadence and rate limits, which would complete the picture.

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?

Content is front-loaded as a scannable list of what the feed returns, followed by the payment requirement and the alternate HTTP endpoint. It is dense but every clause carries information; only the trailing URL is arguably non-essential for an MCP invocation.

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 compensates well by enumerating the return contents and noting sources and timestamp are included. Payment mechanics and the cost are also covered, leaving only update frequency/source cadence unspecified for a single-optional-param read 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 single 'pass' parameter is fully documented in the schema (100% coverage), including its origin (buy_day_pass / POST /api/pass/day) and effect (skips per-call payment), so the schema already does the work. The description's mention of in-band payment only indirectly signals the parameter's role, adding no new syntax or 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 names a specific verb+resource and enumerates the returned content (protocols by TVL, 7d change/flows, movers, launches, yields, top RWA tokens, sources, timestamp), so the agent can tell it apart from generic siblings like get_flows or get_coin. It stops short of explicitly naming which sibling to prefer when the request is ambiguous, so it is clear but not fully differentiated.

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 relative to siblings such as get_flows, get_daily_brief, or get_full_signal. The only alternative mentioned ('Also at GET https://...') is a non-MCP transport path, not a tool-selection rule, so the agent gets no routing help.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the cost model ('Free') and a disclaimer ('Signal only, not financial advice'), implying a read-only, non-destructive call. It omits auth requirements, rate limits, and the fact that the data is a limited sample rather than the full signal set.

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 with no filler, and the payload (what you get) is front-loaded right after the 'Free:' tag. Terms like 'band-dot count' are terse to the point of being cryptic, but the overall structure is tight.

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 compensates by listing the exact fields returned, which is the most useful thing it can do. It is nearly complete for the call itself, missing only the distinction between this sample and the full signal endpoints.

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 no parameters, so per the baseline this dimension is a 4. The description correctly adds no parameter guidance, and its enumeration of returned values is content description rather than 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 names the specific contents returned: Stage 1 regime statuses, core WaveTrend 4h values for five named coins, and a band-dot count. That is a concrete verb-less but resource-specific purpose. It does not, however, explicitly distinguish itself from siblings like get_regime, get_band_dots, or get_full_signal, 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?

The only usage signal is the leading 'Free:', which hints the tool is a no-cost entry point versus paid siblings such as list_paid_endpoints. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g. get_full_signal for the complete dataset), leaving selection largely to inference.

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?

With no annotations, the description carries the burden and does reasonably well: it discloses cost ('Free'), the key algorithm (Ed25519), the header it validates (X-GW8-Signature), and the scope (paid responses only). It does not mention key rotation, caching, or whether the key is static, which are the remaining behavioral gaps.

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 tightly packed sentence: the cost qualifier is front-loaded, then the resource, then the verification target. Nothing is wasted and the most scannable details come first.

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 must indicate what comes back — it names the public key and scheme, which is the essential return content, but does not specify the response shape (e.g. whether the scheme string and key are separate fields). For a zero-param, zero-annotation utility this is nearly 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?

The tool takes zero parameters, so per the baseline there is nothing the description needs to compensate for. No parameter meaning is missing or misleading.

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 precisely what is returned (Ed25519 public key plus signing scheme) and its purpose, with the header name X-GW8-Signature and the scope 'paid responses'. This distinguishes it from the data-feed siblings such as list_paid_endpoints or get_sample, though it relies on an implied 'get' rather than an explicit 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?

'Free:' and 'on paid responses' imply the context of use — call it to verify response authenticity rather than to fetch market data — but no explicit when-to-use or alternative (e.g. why not just trust the payload) is given. Usage is inferable but not stated.

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?

With no annotations, the description carries the full burden and does well: it discloses the $0.01 USDC cost on Base, the in-band x402 payment mechanism and _meta key, an equivalent unauthenticated REST endpoint, and that verdicts come from GoPlus + DexScreener under fixed rules. Not covered are rate limits, failure modes, or what happens on an unsupported chain.

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 value proposition is front-loaded in the first sentence, which is good, but the remaining text is a dense run-on packing the MCP package name, a _meta key, a raw endpoint URL, and payment terms into one paragraph. All of it is arguably actionable, yet the packaging is cramped rather than structured.

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 and no annotations, so the description must cover everything, and it does sketch the return payload and payment flow. Still, gaps remain for a paid, 3-parameter tool: address semantics are unstated, the output is not shaped beyond a list of fields, and no error or unsupported-chain behavior is described.

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 33%: only the optional 'pass' parameter is documented in the schema, while 'chain' and 'address' are bare. The description partially compensates by exposing the URL shape /api/verdict/{chain}/{address}, implying these are path-style identifiers, and by naming buy_day_pass as the source of a pass, but it never explains the expected address format or that chain dominates validity.

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 leads with a specific question ('Is this token safe?') and enumerates the actual product of the call: a 0-100 score, a safe/caution/danger classification, reasons, and named data sources. That is enough for an agent to distinguish it from get_coin or get_full_signal, though it never explicitly contrasts itself with those siblings.

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 framing question (use it when you need a safety judgement on a token), and it usefully discloses that the call is paid and that a day pass via buy_day_pass skips per-call payment. However, there is no explicit when-to-use vs. sibling guidance and no statement of when this is the wrong tool.

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?

With no annotations, the description carries the full burden. It does add real behavioral context — these are paid endpoints settled in USDC on Base (eip155:8453), and paid MCP tools also accept x402 payment in-band — but says nothing about read-only nature, rate limits, or result size/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?

Two short sentences, zero waste, with the core purpose and return content front-loaded ahead of the secondary payment-mechanism note.

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 parameterless list tool with no output schema, the description tells the agent what a row contains (method, URL, price) and the payment context — enough to call it correctly. Only minor gaps remain, such as volume of results or whether the list is static or dynamic.

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 baseline a 4 applies. The description cannot and need not explain parameter semantics, and it correctly implies the call is unfiltered.

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 and resource ('Lists paid x402 endpoints') and immediately names the returned fields (method, URL, USD price). No sibling does anything similar, so no differentiation text is needed for an agent to pick it correctly.

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: an agent can infer this is a discovery call for paid endpoints, but the description never states when to call it (e.g., before calling a paid tool, or to check pricing) nor any alternatives. No exclusions or preconditions are given.

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?

With no annotations at all, the description carries the full load and does it well: 30-day or 300-alert expiry, HMAC-signed payloads, a mandatory $0.50 USDC on Base payment via x402 in-band, and an alternate REST endpoint. Payment and lifetime constraints are exactly the kind of behavior an agent must know before invoking.

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-loads the core action and scope in one dense sentence, then lists args and payment/endpoint details compactly. Tight, though the payment and URL tail is a little crammed 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?

No output schema and no annotations, so the description must be self-sufficient, and it covers lifetime, signing, payment, and the callback contract. It stops short of describing payload shape or whether duplicates/retries occur, but an agent has enough to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it partially does: it pins webhookUrl to public https, marks pairs as optional, and documents the filter enum values. It still never explains the pairs format (symbols vs pair ids) or defaults when filter is omitted, so coverage remains incomplete.

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 (Subscribe) and resource (a public https webhook to NEW green WaveTrend band dots), including the trigger condition and delivery window. It is trivially distinguishable from every sibling, all of which are read-style get_* 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 implies when to use it (to receive alerts on new green dots) and names an alternate transport (the raw POST endpoint), but gives no explicit when-not-to-use or guidance for choosing among the sibling signal tools for someone who only wants to query dots.

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