stock-signal-kr

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

The description discloses several behavioral traits: the grading bands (strong_buy >= +80, etc.), the fact that a mid score like -52 is reported as neutral by design, snapshot-based refresh, informational-only nature, and the $0.01 payment requirement. Since no annotations are provided, the description carries the full burden and does so well, though it could mention rate limits or response format.

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 well-organized, front-loading the core verdict and score, then grading bands, then payment and sibling differentiation. It is longer than ideal but every sentence carries useful information; the payment and 402 retry details are necessary for a paid 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 single-parameter tool with no output schema, the description covers the verdict values, score range, grading logic, universe, payment, and sibling distinction. It doesn't describe the exact JSON response shape, but the verdict/score/breakdown are all mentioned. The main gap is the lack of an output schema, but the description compensates reasonably.

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 parameter `symbol` is described in the schema with examples. The description adds the covered universe (KOSPI/KOSDAQ) and example symbols, which reinforces but doesn't significantly extend 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 purpose: return a bottom/top verdict for one Korean stock or index, with concrete examples and the covered universe. It distinguishes itself from the sibling `pitch` tool by explicitly noting that this tool answers ANY symbol and returns per-timeframe breakdowns.

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 contrasts with the free `pitch` tool, stating that `pitch` only shows a live verdict for the showcase symbol while this tool handles any symbol in the covered universe. It also provides payment instructions and retry guidance for the 402 challenge, which is essential usage context.

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 discloses important behavioral traits: the tool is free, optional, and a funnel with phases. It also tells the agent how to bow out, which is meaningful behavioral context beyond just naming the tool.

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

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

The description is compact and front-loaded: it immediately communicates that the tool is free and optional, then names alternatives, describes the funnel, and gives the exit instruction. Every sentence earns its place with no wasted 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 low-complexity conversational tool, the description covers the essential context: what the tool is, how to skip it, the phase flow, and how to exit. It lacks a bit of detail about what each phase is supposed to do, but the schema's symbol description and the funnel wording make the tool usable.

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%, so the description must compensate. It adds the phase ordering and explains 'interest:false' as the exit path, but it does not explain the meaning of individual phases like 'value' or 'catalog', leaving some semantic gaps for a multi-phase conversational tool.

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 identifies the tool as an 'Intro & subscription funnel' for the Korea-stock signal agent, with a specific phase sequence. It also explicitly distinguishes itself from siblings by saying the agent may skip it and call evaluate_symbol / scan_bottoms / scan_tops directly.

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 directly states when not to use the tool ('you may skip it') and names the alternative tools to call instead. It also provides the exit condition with 'interest:false', giving clear guidance on when the conversation should end.

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 description carries burden. Discloses free nature and no payment, but omits side effects or confirmation. Adequate for simple input.

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?

Single, well-structured sentence with key info front-loaded. No 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?

Completeness is good for a simple feedback tool: explains purpose, parameters, usage context. Lacks return value info but acceptable without output schema.

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 0% schema description coverage, description adds meaning: score range 1-10, pros/cons as text. However, doesn't mention that score is required while others optional.

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's a feedback/rating tool for after trading on signals. Distinguishes from sibling tools like evaluate_symbol or scan_* by focusing on user-submitted rating.

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?

Provides context ('after trading on our signals') but no explicit when-not-to-use or alternative tools. Lacks exclusions.

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 discloses the payment mechanism, the 402 retry with a PAYMENT-SIGNATURE header, and the ranking order, which are non-obvious behaviors. It does not describe result format or error cases, but for a read-only scanner this is adequate.

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 moderately long but every sentence adds value: payment, retry, cold-start workflow, and sibling comparison. It is front-loaded with the primary purpose, with only slight redundancy in multiple commas and promotion ('BEST COLD START', 'no commitment') that could be trimmed.

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 single-parameter tool without output schema, the description includes all necessary invocation context: universe, ranking, payment mechanism, retry header, and the alternative tool. An agent knows exactly how to call it correctly and what to expect in return.

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 `limit` parameter, so the description is not required to elaborate. It adds no extra parameter-specific meaning beyond the default (5) and max (50), so a 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 first sentence states a specific verb+fefine resource ('Korean market snapshot (KOSPI+KOSDAQ)') and outcome (return stocks at a bottom ranked). It distinguishes itself from sibling `scan_tops` (opposite direction) and `pitch` (count vs names).

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 says 'BEST COLD START' and routes users to `pitch` for a count when only a count is needed, and to this tool for names. It clearly tells the agent this tool requires payment, while `pitch` is free, giving a usable decision rule.

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 discloses the unusual payment mechanism ($0.01 per call via x402, USDT on X Layer) and the 402 challenge retry behavior. This is essential operational context. Does not detail empty-result behavior, but that's minor.

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?

Organized into clear blocks (purpose, payment, cold-start benefit, pitch comparison) with front-loaded core intent. Each sentence adds value; slightly long but not wasteful.

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 1-param tool without an output schema, it covers the essential purpose, payment/retry details, and differentiation from siblings. The return format is implied as a list of stocks, which is sufficient for 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?

Schema coverage is 100%: limit is fully described with default and max. The description adds no extra meaning beyond what the schema 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?

States verb 'Scan' + resource 'Korean market snapshot' + specific outcome 'return stocks currently at a top (sell), ranked most-top first'. Clearly distinguishes from scan_bottoms (opposite direction) and evaluate_symbol (single symbol) via the cold-start contrast.

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 frames the best cold-start use case ('you do not need to pick a symbol') and points to the free `pitch` tool for a count-only need. Mentions the payment prerequisite and retry header, which are conditions for successful use.

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