coin-signal

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

No annotations are provided, so the description carries the full burden. It discloses the verdict semantics, scoring bands, the deliberate neutral band, per-call payment, trial duration, 402 retry behavior, and informational-only nature. That is thorough transparency for a paid 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?

Dense and mostly front-loaded, but the long payment/grading tail could be tightened; each clause does add needed information.

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?

Covers the verdict semantics, grading thresholds, sign convention, payment/retry behavior, and distinguishes from the free pitch tool. With no output schema, an agent has enough to know what call will do and what to expect.

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 parameter is already well documented with examples. The description reinforces the example format and clarifies 'any symbol in the covered universe,' but adds only marginal meaning 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?

States a specific action and resource (evaluate a symbol) and defines the output: a bottom/top verdict with score and time-frame breakdown. The explicit contrast with `pitch` distinguishes it from a sibling tool, so an agent can select 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?

The description gives concrete usage context: it works for ANY symbol, unlike the free `pitch` tool which only covers the showcase symbol, and it explains the paid-call flow plus the 402 retry header. This is actionable when-to-use and when-not-to-use 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 behavioral burden and does well: it discloses that the tool is free, optional, multi-phase, and returns structured JSON with a next list. It also warns that the sample phase only serves BTC-USD for free and that other symbols route to paid evaluate_symbol. It does not describe every response detail, but the core behavior is clear.

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 dense but scannable: it front-loads the 'FREE and OPTIONAL' nature and alternatives in the first sentence, then compresses the phase flow into a compact arrow chain. Every sentence contributes useful information and there is 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?

For a tool with no output schema and no annotations, the description is unusually complete: it covers entry, phases, exit, alternatives, and the shape of the return value. The main gap is that it does not describe the full JSON contents of each phase response, but the `next` list is enough for an agent to continue the funnel 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 100%, so the baseline is 3, but the description adds actionable context: it explains the default entry phase, the overall phase progression, and the BTC-USD-only limitation on the sample symbol. This goes beyond the schema's field descriptions and helps an agent pick the right parameter values.

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 purpose: a FREE, optional agent-to-agent intro and subscription funnel. It also distinguishes itself from siblings by explicitly saying you can skip it and call evaluate_symbol / scan_bottoms / scan_tops directly, and by laying out the phase walk from hello to 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 gives explicit usage guidance: call with no args or phase:'hello' to start, follow the listed phases, set interest:false to exit, or bypass the tool entirely for direct analysis via siblings. This clearly tells an agent when to use pitch and when to prefer 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?

No annotations provided, so description carries the transparency burden. It discloses that the tool is free ('costs nothing, no payment header needed'), which is valuable behavioral info. However, it does not mention any side effects, return behavior, or safety aspects beyond cost.

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 'FREE feedback tool'. Every sentence adds value: purpose, when to use, parameter hints, and benefit. No unnecessary words.

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 3-parameter tool with no output schema, the description covers when to use and what to provide. However, it does not specify the return value or any confirmation of the rating submission, leaving a minor gap.

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 reinforces the meaning of parameters (score 1-10, pros, cons) but adds little beyond the schema descriptions. It does provide context ('what was good, what to improve').

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's a feedback tool for rating signals after trading, with a specific verb 'leave a rating' and resource 'feedback'. It distinguishes from sibling tools like evaluate_symbol (analysis) and subscribe (subscription).

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 states 'after you have traded on (or evaluated) our signals', providing clear context for when to use. Does not list when not to use or alternatives, but the context sufficiently differentiates from siblings.

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 provided, the description carries the behavioral disclosure burden and does substantial work: it discloses the $0.01 paid-call model, the 6-day trial switch to a $50 monthly plan, no-account requirement, and the PAYMENT-SIGNATURE retry on 402 challenges. It does not describe rate limits or what happens on invalid symbol lists, but the core call behavior is 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?

The most important purpose statement is front-loaded, and labeled sections (PAY, BEST COLD START) make the payment and cold-start guidance easy to parse. It is a little verbose in the trial/plan details, but each sentence carries information the agent needs.

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 payment flow, auth retry behavior, no-signup expectation, output ordering, and how it differs from pitch, which is strong for a tool with no output schema and complex monetization. It is missing only a small amount of operational detail such as response shape and handling of bad symbols.

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 the baseline is 3; the schema already explains limit and symbols defaults. The description adds a cold-start hint that no symbol is required, though its phrase 'ranks the whole universe' is looser than the schema's 'top-coins set' default and could use reconciliation.

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 sentence names a specific action and resource: scan the market and return coins currently at a bottom, with ranking order ('most-bottom first'). It further disambiguates from the sibling pitch tool by framing this tool as the one that names the bottom coins, not just counts 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 gives clear usage context: it is positioned as the 'BEST COLD START' because no symbol selection is required, and it explicitly routes count-only needs to the free pitch tool. It does not, however, state when to prefer the other market-scan sibling scan_tops or evaluate_symbol, so the guidance is not fully explicit.

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 burden; it covers payment/trial flow, the 402 retry header, no-account requirement, and the no-symbol default. The billing sentence is slightly tangled, so not 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?

Front-loaded with the core behavior, then tight, purposeful additions: ranking, cold-start use, sibling differentiation, and payment handling. No filler sentences.

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?

Covers selection, invocation, output ordering, distinction from pitch, and payment error handling. It does not detail the output shape beyond naming ranked coins, but this is sufficient for tool selection and invocation.

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

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

The schema already documents limit and symbols, but the description adds meaning by explaining that omitting symbols scans the whole universe and that this works as a cold-start call.

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 + object: 'Scan the market and return coins currently at a top', with ranking 'most-top first'. Clearly differentiated from pitch and usable by an agent to select the tool.

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?

Gives direct usage context: it is the cold-start tool, needs no symbol, ranks the whole universe, and explicitly contrasts with `pitch` (count vs. names).

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 provided, the description carries the full burden. It discloses the payment challenge flow (402), the $50 monthly cost, the 6-day trial at $0.01 per call, the 30-day unlimited access, and the returned X-SUB-KEY token. It also mentions the optional agentId linking. This is rich behavioral context, though it doesn't explicitly state side effects like whether activating is irreversible or whether the challenge expires.

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 dense paragraph that front-loads the primary purpose (check status) and then explains the activation flow. It's information-dense but slightly run-on; the sentence about trial pricing and the monthly challenge could be clearer. Still, every sentence earns its place and the structure is logical.

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 tool with no output schema and no annotations, the description covers the essential workflow: how to check, how to activate, what the challenge is, what the token is for, and the pricing. It doesn't describe the exact response format for a status check, but it gives enough for an agent to call it correctly. The main gap is not explaining what happens if you call without activate:true beyond 'check status'.

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 schema already documents both parameters. The description adds meaning by explaining what activate:true does (triggers the payment challenge) and what agentId does (links the subscription), but it doesn't add syntax or format details beyond the schema. Baseline 3 is appropriate.

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 tool's dual purpose: checking subscription status/terms and activating a monthly plan. It specifies the exact verb ('check', 'activate'), the resource ('subscription'), and the distinguishing condition (activate:true). It also differentiates from siblings by being the only subscription-related tool among the listed 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?

The description explicitly explains when to use the tool (to check status or activate) and provides the exact call pattern: call with activate:true to receive the $50 challenge, sign it, and retry. It also explains the trial pricing and the alternative of passing X-SUB-KEY to skip per-call payment, giving clear context for when this tool is needed.

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