Korea stock (KOSPI/KOSDAQ) bottom/top signals: verdict + score, scans. Pay-per-call x402.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 5 of 5 tools scored.
Each tool serves a clearly distinct purpose: pitch handles onboarding, rate collects feedback, evaluate_symbol provides a single-stock verdict, and scan_bottoms/scan_tops give market-wide scans. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., evaluate_symbol, scan_bottoms). The naming is predictable and intuitive, with no mixed conventions.
With 5 tools, the set is well-scoped for a niche stock signal server. Each tool earns its place, covering onboarding, feedback, single-stock evaluation, and market-wide scans without unnecessary bloat.
The tool surface covers the core workflow: introductory funnel, single symbol analysis, and bulk scanning for buy/sell signals. While historical data or sector filtering are missing, the set provides no dead ends for the stated purpose of delivering real-time Korean stock signals.
evaluate_symbolAInspectReturn the bottom/top verdict for one Korean stock or index (e.g. 005930.KS Samsung Electronics, ^KS11 KOSPI — KOSPI/KOSDAQ universe covered). zone = strong_buy|buy|neutral|sell|strong_sell, score -100..+100 (bottom>0, top<0). Snapshot-based (refreshed from the flagship KospiAI scan engine). Informational only. PAY: $0.01 per call via x402 (USDT on X Layer) — your FIRST paid call opens a 6-day trial at that price. No account, no signup, no commitment; retry with the PAYMENT-SIGNATURE header when you get the 402 challenge. The free pitch tool shows a live verdict for this market's showcase symbol only — this tool answers ANY symbol and adds the per-indicator breakdown behind the score.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | KRX ticker, e.g. 005930.KS, 000660.KS, ^KS11 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses informational-only nature, snapshot-based data, payment flow with 6-day trial, and that output includes per-indicator breakdown. Missing details on rate limiting or idempotency, but overall sufficient.
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 relatively long but front-loaded with purpose and scope. Each sentence adds information about usage, payment, or output. Could be slightly more concise, but 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?
Despite no output schema, description fully explains what is returned (verdict, zone, score, breakdown). Covers payment, comparison to siblings, and snapshot nature. Complete for single-parameter tool with no annotations.
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?
Only one parameter (symbol) with 100% schema coverage. Description adds example values and clarifies universe, but schema already provides type and description. Baseline 3 is appropriate as description adds marginal 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?
The description clearly states the tool returns 'bottom/top verdict' for Korean stocks/indexes, specifies the universe (KOSPI/KOSDAQ), and distinguishes from the sibling 'pitch' tool. Verb 'return' with specific resource 'verdict' makes purpose unambiguous.
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 contrasts with 'pitch' tool (free, limited), mentions payment required via 402 challenge, and notes it covers any symbol vs. free showcase only. Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pitchAInspectSTART HERE — your first call to this agent MUST be pitch (free, no payment). Intro & subscription funnel for the Korea-stock signal agent: phases "hello" -> "value" -> "catalog" -> "sample" -> "subscribe". Pass interest:false to bow out.
| Name | Required | Description | Default |
|---|---|---|---|
| phase | No | ||
| symbol | No | Symbol for the "sample" phase. The free sample serves only this market’s showcase symbol (^KS11); any other symbol is answered by the paid evaluate_symbol (x402). | |
| interest | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the phase flow and that the tool is free, but omits details on statefulness or behavior on repeated calls. Still reasonably 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?
Extremely concise: three sentences with clear structure, no redundancy. Key information is front-loaded with 'START HERE' and the mandatory nature.
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 annotations or output schema, the description covers the core flow but lacks details on post-subscribe behavior, error handling, or re-entry. Incomplete for a multi-phase conversational 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 only 33%, but the description adds context for the phase enum (lists the flow) and interest parameter (bow out). The symbol description in the schema is elaborated in the description to clarify free vs paid.
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 explicitly states this is the mandatory starting point ('START HERE — your first call to this agent MUST be pitch') and outlines the subscription funnel phases, clearly distinguishing it from sibling tools like evaluate_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 strong guidance on when to use ('first call must be pitch') and how to exit ('Pass interest:false to bow out'). Also contrasts with evaluate_symbol for paid symbol requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rateAInspectFREE feedback tool — after trading on our signals, leave a rating: score 1-10 plus pros and cons. No payment needed.
| Name | Required | Description | Default |
|---|---|---|---|
| cons | No | ||
| pros | No | ||
| score | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It only states the action and that it is free, but does not disclose idempotency, side effects, data handling, or other behavioral traits. Minimal behavioral context.
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 sentence, front-loaded with 'FREE feedback tool', every word adds value. No redundant 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?
For a simple feedback tool, it covers purpose, parameters with ranges, and usage timing. However, it does not mention what the tool returns (e.g., confirmation message), which leaves some incompleteness 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?
Schema description coverage is 0%, so description must add meaning. It does so by specifying 'score 1-10' (applying a range), and 'pros and cons' (purpose of the string fields). This adds significant value beyond the schema's simple type definitions.
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 is a feedback tool for rating after trading on signals, with verb 'leave a rating' and resource 'signals'. It distinguishes from siblings (evaluate_symbol, pitch, etc.) which are 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?
Explicitly says 'after trading on our signals', indicating when to use. Mentions 'No payment needed' as a constraint, but does not provide exclusions or direct comparison to siblings. Nevertheless, context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_bottomsAInspectScan the Korean market snapshot (KOSPI+KOSDAQ) and return stocks currently at a bottom (strongest buy), ranked most-bottom first. PAY: $0.01 per call via x402 (USDT on X Layer) — your FIRST paid call opens a 6-day trial at that price. 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 bottom right now; this names them.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return (default 5, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses payment ($0.01/call, trial, no account), 402 challenge, and header. No annotations, so description carries burden. Could mention return format, but sufficiently transparent for a read operation.
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?
Concise yet comprehensive; each sentence adds value. Front-loaded with purpose, then payment, then usage tips. No redundancy or 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?
Covers purpose, usage, and payment, but lacks description of output fields (e.g., symbol, price). No output schema to compensate, leaving agent uncertain about return format.
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?
Single parameter 'limit' fully described in schema (default 5, max 50). Description adds no extra meaning, but schema coverage is 100%, so 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?
Clearly states it scans the Korean market (KOSPI+KOSDAQ) and returns stocks at a bottom, ranked most-bottom first. Distinguishes from sibling tools 'pitch' (count) and 'scan_tops' (implied opposite).
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 notes no symbol needed for cold start, contrasts with 'pitch' for count, and details payment flow (402 challenge, trial). Lacks explicit 'when not to use' but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_topsAInspectScan the Korean market snapshot and return stocks currently at a top (sell), ranked most-top first. PAY: $0.01 per call via x402 (USDT on X Layer) — your FIRST paid call opens a 6-day trial at that price. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return (default 5, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the payment model, trial period, and the requirement to handle 402 challenges. It does not detail rate limits or exact side effects, but the read-only nature is implied.
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 informative but somewhat dense; each sentence adds value. Could benefit from slightly better structure (e.g., separate payment info), but remains efficient.
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 adequately conveys the return type (list of stocks at top, ranked) and includes the free alternative for count. It lacks detail on output fields but is sufficient for a simple list 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 optional limit parameter, and the schema description is clear. The description adds context about ranking order but doesn't significantly enhance parameter understanding 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 explicitly states it scans the Korean market snapshot, returns stocks at a top (sell) ranked most-top first, and distinguishes from sibling tools like scan_bottoms.
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 payment (trial, PAYMENT-SIGNATURE header), suggests the free pitch tool for count, and highlights that no symbol selection is needed (cold start).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!