Skip to main content
Glama
meteoroh

tossinvest-mcp

by meteoroh

Get daily price limits

tossinvest_get_price_limits
Read-onlyIdempotent

Check a stock's daily upper and lower price limits before placing a limit order to avoid price-out-of-range rejections. Returns current limits for KRX and US symbols, covering markets with daily bands.

Instructions

Get today's upper and lower price limits (상한가/하한가) for one stock.

Check this before placing a limit order: a price outside the band is rejected with 422 price-out-of-range.

Args:

  • symbol (string): One symbol.

  • response_format ('markdown' | 'json'): default 'markdown'.

Returns { symbol, currency, timestamp, upperLimitPrice, lowerLimitPrice }. Limits are decimal strings; either can be null for markets without a daily band (US stocks generally have none).

Errors: 404 stock-not-found for unknown symbols.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolYesStock symbol. KRX: 6 digits (e.g. '005930' for Samsung Electronics). US: ticker (e.g. 'AAPL').
response_formatNoOutput format: 'markdown' for a compact human-readable summary, 'json' for the complete raw payload.markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolYes
currencyNoKRW or USD
timestampNo
lowerLimitPriceNoDaily lower limit; null when the market has no limit
upperLimitPriceNoDaily upper limit; null when the market has no limit

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior3/5

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about a 404 error and the purpose of the data, but does not introduce any contradiction or require extra behavioral disclosure beyond the annotations.

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

Conciseness5/5

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

The description is concise and well-structured, with a clear purpose sentence, a practical usage hint, and no redundant or unnecessary content.

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

Completeness5/5

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

Given only two simple parameters, a full output schema, and comprehensive annotations, the description provides enough context for an agent to invoke the tool correctly, including an error case and a practical use case.

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 descriptions already cover the parameters fully, including the symbol format and response_format enum. The description does not add substantial new parameter meaning beyond what the schema provides, so 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 clearly states the tool gets today's upper and lower price limits for one stock, using a specific verb and resource. It is distinguishable from sibling tools like get_prices and get_orderbook by focusing on price limits.

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 explicitly says to check this before placing a limit order and explains that out-of-band prices are rejected. It does not explicitly name alternatives, but the use case is clear enough for an agent to know when to select this tool.

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