coin-signal

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

No annotations provided, so the description carries full burden. It discloses that the tool is informational only, not financial advice, and explains the payment mechanism ($0.01 per call, trial, retry with PAYMENT-SIGNATURE header). It does not mention rate limits or idempotency, but the payment disclosure is significant.

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

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

The description is a single paragraph that is dense but not overly long. Every sentence adds value: output description, payment terms, trial info, retry instruction, and sibling differentiation. It could be slightly shorter or better organized, but it's efficient.

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 the absence of an output schema, the description adequately explains the return values (zone, score, daily/weekly/monthly breakdown). It also covers the payment flow and compares with a sibling. Missing details like case sensitivity or pagination, but overall sufficient for a single-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?

With 100% schema coverage, the schema already documents the 'symbol' parameter. The description adds meaning by providing examples of valid symbols (BTC-USD, ETH-USD, BTCUSDT) and clarifying it's a crypto symbol, which helps agents format inputs correctly.

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

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

The description clearly states it returns a bottom/top verdict (zone and score) for one crypto symbol, with daily/weekly/monthly breakdown. It explicitly distinguishes from the sibling 'pitch' tool by noting that pitch only shows a showcase symbol, while this tool answers any symbol and adds per-indicator breakdown.

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 provides clear context on when to use: for any crypto symbol, and contrasts with the free 'pitch' tool. It also includes payment instructions and retry behavior on 402. However, it does not explicitly state when not to use or mention other sibling tools like scan_bottoms/scan_tops as alternatives.

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

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

With no annotations, the description fully discloses the tool's behavior: it's free, a multi-phase funnel, returns structured JSON with a 'next' list, and the sample phase only works for BTC-USD. This covers all necessary behavioral expectations.

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

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

The description is compact and front-loaded with 'START HERE', but the single dense paragraph could benefit from brief bullet points or clearer separation of phases for easier parsing.

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 the tool's complexity (multi-step funnel, no output schema, no annotations), the description covers all essential aspects: entry point, phases, exit mechanism, return structure, and free sample scope. It is self-contained and actionable.

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%, but the description adds critical context: the phase default, the symbol restriction to BTC-USD for free sample, and the use of interest:false for polite exit. This elevates understanding beyond the schema alone.

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

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

The description clearly states that pitch is the mandatory first call for the agent, outlines the funnel phases (hello, value, catalog, sample, subscribe), and distinguishes it from siblings like evaluate_symbol and subscribe by positioning it as the introductory entry point.

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?

Explicitly instructs to start with pitch, describes each phase sequentially, explains how to exit with interest:false, and provides a precise alternative for non-BTC-USD symbols: 'any other symbol is answered by the paid evaluate_symbol'.

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 provided, so the description carries the full burden. It discloses that the tool is free, requires no payment header, and helps tune the engine. However, it does not mention authentication requirements or rate limits, which are relevant for a write operation.

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, efficiently conveying purpose, parameters, usage context, and cost. Every sentence adds value, and the key information is front-loaded.

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

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

For a simple feedback tool with no output schema, the description covers purpose, parameters, usage context, and cost. It does not mention the return value or confirmation, but this is acceptable for such a 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 100%, so the baseline is 3. The description repeats the parameter purpose ('score 1-10 plus what was good (pros) and what to improve (cons)') but adds no new semantics beyond the schema.

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

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

The description clearly states this is a feedback tool for leaving ratings on signals. It specifies the resource (feedback on signals), verb (leave a rating), and scope (after trading/evaluating signals). It is distinct from sibling tools like evaluate_symbol or subscribe.

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 specifies when to use the tool ('after you have traded on (or evaluated) our signals'). It provides clear context but does not explicitly state when not to use it or list alternatives.

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

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

Discloses payment mechanism ($0.01 via x402, 6-day trial), no account required, retry with header. No annotations provided, but description adds good behavioral context beyond basic.

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?

Multiple sentences but each adds value; front-loaded with core purpose. Not overly verbose for the information provided.

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, but description implies a ranked list. Payment and cold start context included. Adequate for a simple list tool with 2 params.

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%; description adds meaning: default limit 5/max 50, symbols optional defaults to top-coins set, ranking method. Baseline 3, extra context earns 4.

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?

Clearly states it scans market for coins at a bottom, most oversold/strongest buy, ranked most-bottom first. Distinguishes from siblings like scan_tops and pitch.

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?

Explicitly mentions best cold start (no symbol needed), contrasts with free pitch tool that tells count. Does not give explicit when-not-to-use but context is clear.

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?

Without annotations, the description must disclose behavior. It covers the payment model ($0.01 per call, trial, retry header) and cold start, but is silent on rate limits, error handling, data freshness, or response format. The payment context is valuable but incomplete for a fully transparent description.

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 well-structured, front-loading the core purpose followed by payment and cold start notes. Each sentence adds value, though it could be slightly more concise. No redundant or tautological statements.

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 no output schema, the description should clarify return format. It says 'return coins' and 'names them' but does not specify if scores or other data are included. Payment and usage details are complete, but the output structure remains vague for a paid 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 coverage is 100% with descriptions for 'limit' and 'symbols.' The description adds context that symbols are optional and default to a top-coins set, and mentions the whole universe ranking. This is helpful but does not dramatically extend the schema content.

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

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

The description clearly states the verb 'scan' and resource 'market,' specifying it returns coins at a top (most overbought/sell) ranked most-top first. It distinguishes itself from sibling 'scan_bottoms' by implying the opposite, and from 'pitch' by naming coins versus counting them.

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

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

The description provides explicit guidance: it notes that no symbol is needed (best cold start) and compares with the free 'pitch' tool for counting. However, it does not explicitly mention when to avoid this tool or alternatives like 'evaluate_symbol' or 'rate.'

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 fully carries the burden and transparently details the activation flow (402 challenge, signing, retrying), consequences (30 days unlimited, X-SUB-KEY token), and linking agentId. It also mentions pricing and trial.

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 efficiently packs all necessary details. It is slightly dense but every sentence adds value, so it is appropriately concise.

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

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

The description covers the two modes, payment flow, token usage, and agent linking. It does not explicitly describe the return format for status checks or failure scenarios, but it is fairly complete for the tool's complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal additional meaning beyond the schema descriptions; it reiterates the activate parameter's role but does not introduce new semantic details.

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

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

The description clearly states two modes: checking subscription status (FREE) and activating the monthly plan with activate:true. It clearly distinguishes itself from sibling tools which deal with trading signals, not subscription management.

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 explains when to use for checking status or activating, and provides context about pricing and trial. However, it does not explicitly state when not to use or mention alternatives beyond the subscription context.

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