seoul-apt-signal

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

With no annotations, the description fully bears transparency. It discloses input formats (Korean/romanized), output (zone, score, price), payment model ($0.01 per call, 6-day trial), and that it is informational only. Lacks explicit output structure details but is sufficiently transparent for a tool without output schema.

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 paragraph front-loads purpose and covers input, output, payment, and sibling differentiation without redundancy. Slightly dense but each sentence adds unique 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?

For a single-parameter tool with no output schema, the description covers all essential aspects: purpose, input formats, output components (zone, score, price, breakdown), payment model, and informational nature. The mention of 'per-indicator breakdown' hints at additional detail not elaborated, but overall 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 coverage is 100%, so baseline is 3. The description adds value by specifying accepted naming conventions (Korean and romanized) and providing examples (Gangnam, 강남구), which clarifies parameter semantics beyond the schema description.

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 the verb 'Return' and the resource 'bottom/top verdict for one Seoul district apartment market (25 districts)'. Explicitly distinguishes from the sibling 'pitch' tool by noting that this tool answers any symbol and provides per-indicator breakdown, while pitch only shows showcase symbol.

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 for when to use this tool vs 'pitch' (paid, any symbol vs free, showcase only). Does not address when to prefer 'rate', 'scan_bottoms', or 'scan_tops', so some usage ambiguity remains.

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 partly discloses behavior (free, no payment, phase sequence, sample constraint) but does not address idempotency, side effects of repeated calls, or detailed response behavior. More context on statefulness or re-call consequences would improve transparency.

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?

Extremely concise: two sentences with no wasted words. The key instruction 'START HERE' is front-loaded, and the funnel phases are listed compactly. 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?

For a simple funnel tool with no output schema, the description covers the essential context: it is free, has a defined phase sequence, and handles a special case for sample. Minor gap: it does not describe expected return values or error messages, but given the tool's nature, it meets needs.

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 description adds significant meaning: it explains the phase sequence, specifies that symbol is only relevant for the sample phase and limited to 강남구, and clarifies that interest:false bows out. This compensates for the schema gaps.

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 the mandatory first call for the agent, detailing its purpose as a free subscription funnel with specific phases. It distinguishes itself from sibling tools like evaluate_symbol by noting that the sample phase only serves a specific district, directing other queries elsewhere.

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 that the first call must be pitch, explains how to opt out (interest:false), and provides guidance on phase progression. It also specifies when to use the sibling tool evaluate_symbol for districts other than 강남구.

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 must convey behavioral traits. It notes the tool is 'FREE' and 'No payment needed,' but does not disclose whether the feedback is stored, updated, or has side effects. For a simple feedback tool, this is 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 a single, concise sentence that front-loads key information ('FREE feedback tool') and covers what the tool does and its input requirements without 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?

Given the tool's simplicity (3 parameters, no output schema, no nested objects), the description is fairly complete. It explains the tool's purpose, usage timing, and parameter roles. It lacks details on return values or side effects, but the tool is straightforward.

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. It adds meaning by stating 'score 1-10 plus pros and cons,' implying the score range and that pros/cons are text. This adds constraints beyond the schema (which only says number for score).

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 is a 'FREE feedback tool' for leaving a rating after acting on signals. It specifies the components: score 1-10 plus pros and cons. This distinguishes it from sibling tools like evaluate_symbol or scan_tops, which are analysis or scanning 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 provides context: 'after acting on our signals'. It implies when to use the tool, but does not explicitly state when not to use it or mention alternatives. The guidance is clear enough for its purpose.

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. Discloses payment model ($0.01 per call, trial period, x402 method), retry instructions, and no account needed. Lacks details on rate limits or data freshness.

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 front-loaded with core purpose, then adds payment and usage notes. Each sentence adds value, though slightly verbose with payment details. Overall well-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?

Covers purpose, output (ranked list with price-per-pyeong), payment, and usage hint. No output schema, but description mentions the key output fields. Adequate for a simple one-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 coverage is 100% for the single parameter 'limit', and the description adds no additional meaning beyond the schema's description. 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 'Scan all 25 Seoul districts and return those currently at a bottom (strongest buy), ranked most-bottom first, 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?

Provides a 'BEST COLD START' hint that no symbol selection is needed, and mentions the free pitch tool for counts. Implicitly guides when to use this tool, though lacks explicit 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?

No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: the tool costs $0.01 per call via x402, the first call opens a 6-day trial, and retries require a PAYMENT-SIGNATURE header. It also notes no account or signup is needed. However, it does not explicitly state the tool is read-only or mention rate limits, which would further enhance transparency.

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 front-loads the purpose, then adds payment details, a cold start tip, and a reference to the sibling tool. Every sentence contributes value, and the structure is logical, though it could be slightly more compact.

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 tool with one optional parameter and no output schema, the description covers the purpose, usage context, payment flow, and relationship to the sibling 'pitch' tool. The main gap is the missing specification of the output format (e.g., list of district names or objects), but this is minor given the tool's simplicity.

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 has 100% coverage for the single parameter 'limit', which already states 'How many to return (default 5, max 25)'. The description adds that results are ranked 'most-top first' but does not provide additional semantics beyond what the schema offers. 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 it scans all 25 Seoul districts and returns those at a top (overheated, sell), ranked most-top first. This is a specific verb+resource+result, and it implicitly distinguishes from siblings like 'scan_bottoms' (opposite) and 'pitch' (count only).

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 for when to use this tool: it is the best cold start because it ranks the whole universe without needing to pick a symbol. It also references the free 'pitch' tool for counting. However, it does not explicitly state when not to use it or contrast with alternatives like 'evaluate_symbol' or 'scan_bottoms'.

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 key behaviors: activation triggers a 402 payment challenge, need to sign and retry, returns a token for 30-day unlimited calls, and optional agentId linking. Since no annotations are provided, the description adequately covers the tool's mutability and side effects.

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, long paragraph mixing multiple concepts (check status, activation flow, payment details). It could be more structured (e.g., bullet points) to improve readability, though it remains informative.

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 activation flow and return token, but does not specify the output for the 'check' case (e.g., what status returns) or what happens if no parameters are passed. Somewhat complete but leaves minor 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 coverage is 100%. Description adds meaning beyond schema: explains that 'activate' triggers a payment challenge and 'agentId' is for linking. Provides context on the flow (sign, retry, token).

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: checking subscription status/terms or activating the monthly plan. It distinguishes itself from sibling tools (evaluate_symbol, pitch, rate, scan_bottoms, scan_tops) which are unrelated financial analysis 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 guidance on when to use the tool (check status or activate with 'activate:true') and mentions the trial period and per-call cost before subscribing. Does not explicitly exclude alternatives, but siblings are unrelated so not necessary.

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