Skip to main content
Glama

seoul-apt-signal

scan_tops

Scan all 25 Seoul districts and return those currently at a top (overheated, sell), ranked most-top first. PAY: $0.01 per call via x402 (USDT on X Layer). No account, no signup, no commitment; retry with the PAYMENT-SIGNATURE header when you get the 402 challenge. BEST COLD START: you do not need to pick a symbol — this ranks the whole universe for you. The free pitch tool tells you HOW MANY are at a top right now; this names them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many to return (default 5, max 25)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations present, the description carries the full transparency burden. It clearly discloses the $0.01 payment requirement, the x402 flow, the PAYMENT-SIGNATURE retry behavior, the lack of account requirements, and the ranking behavior. It does not, however, describe the exact output shape, which is left unspecified without an 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.

Conciseness4/5

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

The description is longer than typical but nearly every sentence carries operational value: payment handling, cold-start use case, ranking, and differentiation from `pitch`. It is somewhat marketing-toned ('BEST COLD START'), but not padded.

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

Completeness4/5

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

An agent has enough to invoke the tool correctly: what it scans, how results are ordered, the default use case, and the payment/retry protocol. The main omission is that there is no output schema and the description never states the shape of the response.

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

Parameters3/5

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

The schema already fully documents the single `limit` parameter at 100% coverage DNA. The description adds no parameter-level meaning, but at 100% schema coverage, the baseline of 3 is appropriate.

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

Purpose5/5

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

The description uses a specific verb and object: 'Scan all 25 Seoul districts' and 'return those currently at a top,' with the output explicitly ranked most-top first. It also distinguishes itself from the free `pitch` tool and makes its role as a cold-start universe scan clear.

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

Usage Guidelines4/5

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

The description gives strong context: best as a cold-start tool, does not require picking a symbol, and contrasts with the free `pitch` tool for counting tops. It does not explicitly name every sibling alternative, but the wording makes when to use it reasonably clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources