seoul-apt-signal

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

No annotations provided. Description discloses informational nature, payment requirement, retry mechanism on 402, trial offer, and addition of per-indicator breakdown. Transparent without contradictions.

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?

Description is somewhat long but well-structured with key details front-loaded. Every sentence adds value, though could be slightly more 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?

Given simple tool with one parameter and no output schema, description fully explains inputs, outputs, usage, payment, and error handling. No gaps.

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 covers 100% with example, but description adds value by specifying accepted formats (Korean, romanized) and listing examples like 'Gangnam, 강남구, Nowon', going beyond 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 it returns a bottom/top verdict for one specific Seoul district, with details on output (zone, score, price). It distinguishes from siblings like 'pitch' (free but limited) and scan 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?

Provides clear context: use for any district symbol, mentions free alternative 'pitch' for showcase, and describes payment model. Lacks explicit when-not-to-use but sufficient.

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 provided, so the description carries full burden. It describes the funnel flow and that it's free, but does not disclose whether it creates a session, stores state, or has side effects. Adequate but not exhaustive.

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 reasonably concise, front-loaded with the key instruction 'START HERE', and each clause adds value. Slightly verbose but well organized.

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 and moderate complexity, the description explains the input flow well but does not describe the return value or expected response format, leaving the agent to infer behavior.

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 low (33%), but the tool description explains the phase enum values and the symbol parameter's limitation (only free for 강남구). The interest parameter is also addressed. Adds significant 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?

The description clearly states this tool is the mandatory first call, defines the subscription funnel phases, and distinguishes itself from siblings by specifying when to use evaluate_symbol instead (for non-default districts in sample phase).

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 it must be the first call and hints at bowing out with interest:false. Provides an alternative for the sample phase. However, it does not cover when to use other sibling tools like rate or scan_*.

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 bears full burden. It only mentions the tool is free and no payment needed, but omits behavioral traits like whether it updates existing feedback, permissions required, or side effects on other data.

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 concise sentences, front-loaded with key information. 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 simple feedback tool with 3 parameters and no output schema, description covers the essential usage context (after signals, free, rating with pros/cons). Could mention where the feedback is stored or how it affects future signals, but overall adequate.

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%. Description adds meaning by stating score range (1-10) and the existence of pros/cons, but does not explain format or constraints for those string fields. Adds some value beyond 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?

Description clearly states the tool is for leaving a rating (score 1-10 plus pros/cons) after acting on signals. This distinguishes it from sibling tools like evaluate_symbol, pitch, etc., which are analysis/action tools, making this a feedback follow-up.

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?

Specifies when to use: 'after acting on our signals'. Provides clear context, but does not mention alternatives or exclusions. Still, the timing guidance is explicit and helpful.

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 full burden. It discloses payment cost, trial, retry header, and that no account is needed. However, it does not explicitly state read-only nature or rate limits.

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?

Description is informative but slightly verbose. It packs essential details (purpose, payment, cold start) in a structured way, though could be more concise without losing clarity.

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 explains that the tool returns districts ranked by bottom strength with price-per-pyeong. It also covers payment and usage context. Lacks exact return structure details.

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 'limit' parameter, which already describes its purpose. The description does not add extra meaning beyond that, so baseline of 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?

Description clearly states the tool scans all 25 Seoul districts and returns those at a bottom (strongest buy), ranked with price-per-pyeong. It distinguishes from sibling tools 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?

Explicit guidance: suggests using 'pitch' first to know how many are at bottom, then this tool to name them. Also explains cold start advantage (no symbol pick) and payment process.

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?

The description discloses payment requirements ($0.01 per call via x402), a 6-day trial on first paid call, and retry instructions. However, it does not mention rate limits, data freshness, or whether the operation has side effects beyond payment.

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 is clear, though it includes verbose payment details that could be slightly condensed. Every sentence adds value.

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 purpose, ranking, payment, trial, and cold start advice, but does not specify the return format (e.g., array of district names or objects), which is a gap given no 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?

The input schema already describes the single parameter 'limit' with default 5 and max 25. The tool description adds no extra meaning beyond ranking all districts first, so baseline score 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 clearly states that the tool scans all 25 Seoul districts and returns those currently at a top (overheated, sell), ranked most-top first. This distinguishes it from siblings like scan_bottoms 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?

The description provides explicit guidance: it is best for a cold start as no symbol selection is needed, and points to the pitch tool for counting. It also explains payment and retry behavior.

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 discloses key behaviors: the 402 payment challenge, token return, per-call cost, trial period, and optional agent linking. Could be more structured but covers important aspects.

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 run-on paragraph with three sentences conveying multiple pieces of information. Could be better structured for readability.

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

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

Given the complexity of subscription activation and payment flow, the description adequately explains the process, token return, and pricing. Lacks explicit return value info but that's implied.

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 has 100% parameter coverage; description adds context: 'activate' triggers payment challenge, 'agentId' links to subscription. Adds value beyond schema descriptions.

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 specifies the tool's two modes: checking subscription status (FREE) and activating the monthly plan with activate:true. It distinguishes from sibling tools (evaluate_symbol, etc.) which are unrelated to subscriptions.

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 explicit guidance on when to use each mode (check vs activate), including the payment challenge flow and token usage. While it doesn't state when not to use siblings, siblings are sufficiently different to not require exclusion.

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