Skip to main content
Glama
mkkim2102

finance-mcp-server-ko

by mkkim2102

get_price_limits

Fetch today's upper and lower price limits for a single Korean stock ticker to determine the allowable trading range for the day.

Instructions

Get today's upper/lower price limits for a single symbol. (상한가/하한가 조회)

Args: symbol: A single ticker symbol, no market prefix, e.g. '005930'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the safety/behavior burden. The verb 'Get' and the explicit 'today's upper/lower price limits' signal a read-only, time-scoped query, and the no-market-prefix rule is a useful constraint. It does not cover invalid-symbol or market-hours behavior, but these are minor for such a simple fetch.

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?

Two compact sections: a one-line functional summary with a helpful Korean gloss, followed by a short Args note. No filler, and the key scoping detail is front-loaded.

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?

For a single-parameter read tool with an output schema, this is nearly complete: it states what is returned, for which symbol format, and for which day. It could add an explicit market/exchange note, but the example and Korean term make the intended domain clear.

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

Parameters5/5

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

Schema coverage is 0%, so the description is the only place the agent learns what 'symbol' means. It provides the type ('ticker symbol'), the constraint ('no market prefix'), and a concrete example ('005930'), which is exactly the detail needed to call the tool correctly.

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?

States a specific verb (Get), a precise resource (today's upper/lower price limits), and a scope (single symbol). This clearly distinguishes it from sibling tools like get_current_price or get_candles, and the Korean equivalent removes ambiguity about what is being queried.

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 clear context: use it when you need today's price limits for a single symbol, and it explicitly warns the symbol must not include a market prefix. It does not name alternatives or exclusions, so it stops short of a 5.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mkkim2102/finance-mcp-server-ko'

If you have feedback or need assistance with the MCP directory API, please join our Discord server