tossinvest-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes, and the verb_noun naming helps. However, get_technical_summary overlaps with several individual indicator tools (RSI, MACD, Bollinger, etc.), which could cause an agent to call redundant tools, so a slight deduction.
Naming Consistency5/5
All tools use consistent snake_case, with get_ for data retrieval and verbs (create/modify/cancel/log) for actions. This pattern is uniform and predictable.
Tool Count2/5
With 36 tools, this is well above the 25 threshold for 'too many.' While each tool may serve a useful function, the sheer volume makes the set heavy and harder for an agent to navigate.
Completeness5/5
The server covers the full investment workflow: account info, market data, technical analysis, order management, risk management, and trade logging. No obvious dead ends; an AI agent can make informed trades and track them.
Average 3.7/5 across 36 of 36 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 18 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only implies a read operation via '조회' but does not disclose whether it requires specific permissions, reflects only settled positions, or returns zero when no holdings exist. No side effects or edge-case behavior is mentioned.
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 a single, front-loaded sentence with no filler or redundant information. It is appropriately sized for the simplicity of the tool and its two-parameter schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema or annotations, and the description does not explain the return format, edge cases, or account-specific behavior. Given its role in checking sellable quantity before trading, key context like account-level interpretation and dependence on current holdings is missing.
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 input schema covers both parameters with clear descriptions, so the baseline of 3 applies. The description adds no extra meaning beyond the schema; '특정 종목' maps to 'symbol', but 'account_seq' is not referenced in the description at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the verb '조회' (retrieve) with a specific resource '매도 가능 수량' (sellable quantity) of a specific stock, clearly distinguishing it from sibling tools like get_holdings or get_buying_power. However, it omits the account-scoping dimension, which is a required parameter and an important part of the tool's identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided; the description simply states what the tool does without indicating when to use it over alternatives like get_holdings or get_position_risk. It also does not mention prerequisites such as having a valid account or existing holdings for the stock.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only mentions that the tool 'calculates' and 'returns' specific values, but it does not mention prerequisites (e.g., sufficient price history), error behavior, or side effects. Since the operation appears read-only, the lack of any explicit safety or data-requirement note is a notable omission.
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 a single concise sentence that immediately states the purpose and lists the return values. Every word adds value, with no redundancy or irrelevant information. It is well-structured and easily parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description is responsible for explaining return values. It lists the components (SMA, bands, %B, bandwidth) but does not describe their structure or format. Also, the absence of usage guidance relative to siblings and the lack of behavioral details make the description only partially complete. Given the tool's complexity (5 parameters, no output schema, no annotations), a score of 3 reflects the clear gaps while acknowledging the output composition is at least mentioned.
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 input schema provides 100% coverage with descriptions for all parameters, including defaults and enums. The description adds no additional meaning to the parameters themselves; it only describes the outputs. Thus the baseline of 3 is appropriate, as the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool calculates Bollinger Bands for a stock (종목의 볼린저 밴드를 계산합니다) and lists specific return values (SMA, upper/lower bands, %B, bandwidth). This clearly identifies the resource and the metrics, but it does not explicitly contrast with sibling indicator tools like RSI or MACD, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling technical indicator tools (e.g., get_rsi, get_macd, get_ichimoku). The description only explains what it does, leaving the agent to infer any usage context. This is a clear gap given the crowded space of indicator tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral context. It discloses the output components but omits important details such as the price basis (e.g., close price), minimum historical data requirements, or any limitations that might affect results. This lack of transparency could lead to incorrect interpretation.
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 two concise sentences: the first states the primary function, the second details return values. It is front-loaded, free of redundancy, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich with full parameter documentation, but the description lacks usage context, such as when to choose MACD over other indicators or what data conditions are needed. Since the tool is relatively simple and the schema covers parameters, a score of 3 reflects the missing usage guidance in the context of many technical-analysis siblings.
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?
All five parameters are fully documented in the schema (symbol, interval, fast_period, slow_period, signal_period) with descriptions, defaults, and an enum for interval. The tool description adds no additional parameter semantics beyond the schema, so the baseline score 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 calculates MACD for a stock and explicitly lists the returned components (MACD line, signal line, histogram, crossover signals). This verb+resource+output structure distinguishes it from sibling indicator tools such as get_rsi or get_stochastic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other technical indicators, nor any mention of prerequisites or conditions. The description simply states what it calculates without offering selection criteria, leaving the agent without context for choosing this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the rate is reference-only and updated every minute, providing useful behavioral context beyond the tool name. However, with no annotations, it does not cover output format, historical data limitations, or other operational details that would fully inform the agent.
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 a single concise sentence in Korean that effectively communicates the tool's purpose and update cycle without unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not indicate what the response contains (e.g., the rate value, timestamp) or how the optional date_time parameter affects the result. This leaves the agent with gaps in understanding the tool's full behavior.
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 input schema already describes all parameters clearly (base_currency, quote_currency enums, and date_time with ISO 8601 format), achieving 100% coverage. The description adds no extra parameter semantics, so the baseline score 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 it queries KRW↔USD exchange rate information, using a specific verb and resource. It also mentions the reference nature and update cycle, distinguishing it from sibling tools focused on stocks, orders, and market data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions or specific use cases. It only states the tool's function without contextual placement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of disclosing behavioral traits. It mentions the data returned and market scope but does not explicitly state that it's a read-only operation, whether authentication is required, rate limits, or data latency. This leaves significant ambiguity for an agent.
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 two concise sentences in Korean, front-loaded with the core purpose and scope. Every word earns its place, with no redundant or vague phrasing.
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 simple read-only query with well-documented parameters, the description lists the key return fields (quantity, purchase price, valuation, profit/loss) and market scope. It lacks explicit output format or error handling, but given the tool's simplicity and no output schema, this is a minor gap.
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?
Schema description coverage is 100% for both parameters, with detailed descriptions including examples. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the account's stock holdings with specific fields (quantity, cost, valuation, P/L). It specifies the scope (domestic and US stocks), which aids in distinguishing it from other tools. However, it doesn't explicitly differentiate from the sibling get_position_risk, so I deduct one point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying holdings and notes the inclusion of both domestic and US stocks, giving context about when it's appropriate. However, it doesn't explicitly state when to use this over alternatives like get_position_risk or get_accounts, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic calculation and spike detection without describing what the tool returns (e.g., moving average series, spike flags), how to interpret results, or any side effects or limitations.
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 two concise sentences, front-loaded with the core purpose and supplemented by the spike detection feature. Every word earns its place, and there is no redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It lacks essential information about the return format (e.g., MA values, spike signals), and does not differentiate from similar technical indicator tools in the sibling list. An agent would not know what to expect from the tool's 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?
Schema descriptions cover 100% of parameters, including period, symbol, interval, and spike_threshold, with details like default values and ratio thresholds. The description's mention of 'current/average volume ratio' aligns with spike_threshold but adds little beyond the schema's own explanation.
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 calculates a stock's volume moving average and detects volume spikes using current/average volume ratio. The verb '계산합니다' specifies the action, and the resource '거래량 이동평균' is specific, distinguishing it from other volume-related siblings like get_obv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for detecting volume spikes, which gives some contextual guidance. However, it does not explicitly state when to use this tool over alternatives (e.g., get_obv, get_technical_summary) or provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only repeats the status filter information already in the schema and does not mention read-only nature, pagination behavior, required account_seq, or any 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences, front-loaded with the primary purpose. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, this description is minimal. It gives the core purpose but omits high-level context such as two distinct modes (OPEN/CLOSED) having different parameter support, date range semantics, or response structure. The schema compensates, but the description itself is not fully complete.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds no new parameter meaning beyond repeating the status enum, and it does not clarify parameter interactions like limit/cursor being CLOSED-only.
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 explicitly states it retrieves an order list and filters by status (OPEN/CLOSED), providing a specific verb and resource. This clearly distinguishes it from the sibling tool 'get_order', which implies a single-order lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for listing orders with a status filter but does not explicitly mention when to use this tool versus get_order or other order-related tools. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It does disclose that the tool calculates and returns three specific outputs, which is useful, but it omits details such as data source, potential side effects, or any limitations. Since this is a read-only calculation, the lack of mutation warnings is less critical, but the description could be more explicit about its behavior.
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 two concise sentences in Korean, front-loaded with the action and followed by the output specifics. Every word earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple indicator calculator, the description covers the core purpose and output shape. However, it lacks alternatives guidance and does not clarify the return format beyond high-level concepts, which leaves minor gaps for an agent selecting among many similar tools. It is adequate but not enriched.
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?
Schema coverage is 100%, so all parameter descriptions exist in the input schema. The tool description adds no extra meaning beyond the schema, which is sufficient, resulting in the baseline score.
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 states a specific verb '계산합니다' (calculates) with a clear resource, 'Parabolic SAR', and explicitly lists the output concepts (trend direction, reversal signal, trailing stop baseline). This clearly differentiates it from sibling indicator tools like get_rsi or get_macd, which focus on different indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or exclusions relative to the many sibling indicator tools, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It only mentions the batch limit but does not describe the response format, error behavior when exceeding 200 symbols, rate limits, or explicitly confirm the operation is read-only. This is a significant gap for a tool with no other behavioral metadata.
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 one concise sentence in Korean that states the core function and the key constraint. No filler, and it is immediately understandable. It earns its place with minimal wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the missing output schema and annotations make the response format unknown. The description does not mention what the response contains (e.g., price per symbol) or any error conditions. It is adequate for knowing how to invoke the tool but incomplete for fully anticipating the result.
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 thoroughly documents the symbols parameter (comma-separated, max 200, examples), and the description repeats the maximum limit without adding new semantics. The description does add that the operation returns current prices, but that is beyond the parameter itself. With 100% schema coverage, baseline 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 queries current stock prices (현재가를 조회합니다) with a specific verb and resource. It also specifies the batch capability up to 200 symbols, which distinguishes it from sibling tools like get_orderbook or get_candles that serve different data needs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for fetching current quotes and gives a practical limit of 200 symbols per call, but it does not explicitly state when to use this versus alternatives (e.g., get_candles for historical data) or any exclusions. This is an implied usage context but lacks clear differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add context about the calculation method (Wilder smoothing) and the outputs (signal line, crossovers), but it does not explicitly state side-effect-free operation, data requirements, or response format. The description adds some transparency but leaves gaps.
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 two sentences, with the first sentence stating the core function and the second adding method and output details. It is front-loaded, concise, and every phrase adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description needs to provide substantial context. It covers the calculation method and key outputs, but it does not specify the return structure, required historical data, or how parameters like overbought/oversold shape the output. For a 6-parameter indicator, this is adequate but not fully complete.
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?
Schema description coverage is 100%, so all six parameters are already documented in the schema. The description adds conceptual context around the signal line and crossover, which relates to signal_period, but it does not provide additional parameter-level meaning beyond the schema. Baseline 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 calculates RSI for a stock, using a specific verb and resource. It further distinguishes itself from sibling indicator tools by specifying Wilder's smoothing method and the additional outputs (overbought/oversold zones, signal line, crossover signals), making its purpose unambiguous and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling indicator tools like get_stochastic and get_macd, there is no mention of scenarios favoring RSI or any exclusions. The usage context is only implied by the tool's name and basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys that the tool is a read-only inquiry (조회) scoped to the day's recent executions, which is useful context. However, it does not disclose ordering, pagination, rate limits, or any other behavioral nuances beyond the basic scope.
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 a single, front-loaded sentence in Korean that states the tool's purpose with no redundancy or filler. It is optimally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description and lack of output schema leave unanswered what the returned trades contain (e.g., price, volume, timestamp). Additionally, the absence of usage guidance makes it less complete when considering the large set of sibling market data tools.
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 input schema fully describes both parameters: symbol with an example and count with default and maximum values. Since schema coverage is 100%, the description does not need to add parameter details, and the baseline score 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 retrieves today's recent trade execution history for a stock, using the specific verb '조회' (retrieve) and resource '체결 내역' (trade executions). It distinguishes itself from market data siblings like get_orderbook, get_candles, and get_prices by focusing on executed trades, and from get_trade_log which is the user's own trade log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It lacks exclusions, comparisons, or context about preferred scenarios, making it inadequate for tool selection among the many market data siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It does not disclose that creating an order is a mutating action with potential financial consequences, nor does it mention side effects like actual execution, the need for confirmation for large orders, or what happens on success/failure. The description is very thin on behavioral context beyond the basic action.
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 two concise sentences, front-loading the core purpose and immediately giving the most critical usage constraint. Every sentence adds value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 10 parameters and no output schema, the description is incomplete. It does not explain how order_type (LIMIT/MARKET) affects price requirements, the meaning of time_in_force options, or the purpose of confirm_high_value_order and client_order_id. The schema covers these individually, but the description lacks high-level guidance on typical order scenarios, which is critical for a trading tool.
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?
Schema coverage is 100% with detailed parameter descriptions. The description adds clarity by restating the mutual exclusivity of quantity and order_amount and the US-only restriction, but this information is already present in the schema (e.g., order_amount says 'quantity와 둘 중 하나만 사용'). Since it does not add meaning beyond the schema, 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 '매수 또는 매도 주문을 생성합니다' (creates buy or sell orders), using a specific verb and resource. It distinguishes from sibling tools like modify_order and cancel_order by focusing on new order creation. The additional note about quantity/order_amount further clarifies scope.
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 provides practical guidance on specifying either quantity or order_amount, and explicitly states that order_amount is for US stock market orders only. This helps the agent choose the right parameters, though it does not explicitly contrast with modify/cancel alternatives or mention preconditions like authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The verb '조회' implies a read-only operation, but the description does not disclose any behavioral details such as return structure, pagination, or data depth. It is adequate for a simple lookup but adds minimal context beyond the basic purpose.
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 a single, front-loaded sentence with no unnecessary words. It efficiently conveys the core functionality without redundancy.
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?
With only one parameter and no output schema, the description gives a reasonable summary of the response content (bid/ask quotes and quantities). However, it does not specify the order book depth or response structure, which would be helpful but not critical given the tool's simplicity.
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?
Schema description coverage is 100%, and the schema already documents the 'symbol' parameter with an example. The tool description adds no additional parameter meaning, so it aligns with the baseline for high schema coverage.
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 retrieves bid/ask quotes and quantities for a symbol, using the specific verb '조회합니다'. This distinguishes it from sibling tools like get_stochastic or get_candles, which serve different data purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention situations where get_orderbook is preferred over get_prices or other market data tools, and there are no explicit exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only states the calculation intent and does not disclose potential side effects, required permissions, or output structure. For a calculation tool, this is acceptable but limited.
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 concise sentences that front-load the core functionality and then state the usage context. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 8 parameters and no output schema, the description does not explain the calculation methodology beyond 'ATR-based', nor does it mention dependencies like account_seq being obtained from get_accounts. It lacks details on return values and edge cases, making it insufficient for a complex risk-calculation tool.
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 input schema covers 100% of parameters with descriptive comments, including formulas (e.g., atr_multiplier). The description adds overall context but no additional parameter semantics beyond what the schema already provides.
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 it computes ATR-based stop-loss price and position size relative to account balance, using a specific verb (계산합니다) and resource (리스크 관리). This distinguishes it from sibling technical indicator tools and order execution tools.
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 indicates it should be called before order execution for risk management in AI automated trading, providing clear usage context. However, it does not mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It does state the return values (e.g., %K, %D, overbought/oversold) which gives some transparency, but it does not mention potential limitations such as insufficient historical data, error handling, or authentication requirements. The description is adequate but not rich in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence in Korean that efficiently states the tool's purpose and outputs. Every word earns its place, with no irrelevant details or repetition.
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?
There is no output schema, so the description's enumeration of return values (%K, %D, overbought/oversold, crossovers) provides a clear expectation. However, it does not describe the response format (e.g., array of objects) or mention the need for historical price data. For a 5-parameter tool, these are minor gaps, making it nearly complete.
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?
Schema coverage is 100% with all five parameters described, so the baseline is 3. The description adds a label 'Slow Stochastic' which aligns with the smooth_k parameter's meaning, but it does not enrich understanding of parameters beyond what the schema already provides. No additional semantic value is offered.
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 that the tool calculates the Slow Stochastic for a stock and lists the specific outputs: %K, %D, overbought/oversold zones, and crossover signals. This distinguishes it from sibling technical indicators by naming the exact indicator, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like RSI or MACD. It does not mention any exclusions, prerequisites, or conditions that would help an agent decide to choose this tool over others, leaving the selection process without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses a key limitation (filled orders cannot be canceled) which is valuable, but it does not explain side effects, error conditions, or behavior for partially filled orders. This is moderate transparency beyond the schema.
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 two short sentences, with the primary action in the first sentence and a critical constraint in the second. It is front-loaded, concise, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and a key limitation, but for a mutation tool without annotations or output schema, it lacks information about success/error responses and preconditions like order status verification. Given the tool's relative simplicity, it is minimally complete.
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 input schema already provides 100% parameter descriptions for order_id and account_seq, including a reference to get_accounts for account_seq. The tool description adds no additional parameter semantics beyond what the schema states, so a baseline score 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 'Cancels an existing order' with a specific verb and resource, distinguishing it from sibling tools like create_order and modify_order. The additional constraint about filled orders adds useful specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (canceling orders) but does not explicitly compare with alternatives like modify_order or instruct to check order status first. The note that filled orders cannot be canceled implies a precondition, but no explicit alternative or exclusion is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It adds meaningful context by specifying the calculation is cash-based and assumes no unsettled receivables ('미수 미발생 기준'), which is a useful caveat. However, it does not explicitly state that this is a read-only operation (though '조회' implies it), nor does it disclose other potential limitations like pending orders or error conditions.
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 a single, compact sentence that front-loads the primary action (조회) and resource. It contains no redundant or filler words, and the parenthetical '미수 미발생 기준' adds a necessary qualifier without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter query with no output schema, the description provides the essential purpose but lacks details about the return value format (e.g., numeric amount, currency) and potential error scenarios. Given the simplicity of the tool, it is minimally adequate but leaves room for clarification.
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?
Schema description coverage is 100%, with both parameters already clearly described (currency enum and account_seq from get_accounts). The description adds no extra meaning about the parameters 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's function: querying cash-based buying power available for buy orders. The verb '조회' (query) and resource '매수 가능 금액' (buying power amount) are specific, and the condition '미수 미발생 기준' distinguishes it from potential alternatives like margin-based calculations. It uniquely identifies this tool among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for buy orders by stating '매수 주문 시', giving clear context. However, it does not explicitly mention when not to use it or point to alternative tools, such as get_sellable_quantity for sell-side checks. There is no comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. However, it merely restates schema constraints (interval enum and max 200) without adding unique behavioral context such as ordering, pagination, or default adjusted setting. No additional side effects are mentioned.
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 consists of two sentences, front-loading the core purpose and then adding brief interval/count details. Every word is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple read tool but omits return format and ordering details. Since no output schema exists, it would benefit from stating that the response is an array of candles and how pagination works via the 'before' parameter.
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 input schema already provides comprehensive descriptions for all 5 parameters with 100% coverage. The description adds no new parameter semantics beyond what the schema documents, earning the baseline score of 3.
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 retrieves OHLCV candle data for a given symbol, using a specific verb ('조회합니다') and resource. It also specifies supported intervals (1m/1d) and return limit, distinguishing it from sibling technical indicator tools.
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 establishes the use case—retrieving historical candle data—but does not explicitly compare with alternatives like get_prices or get_orderbook. It implies usage context but lacks exclusions or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states it uses candle data and returns a time series, but does not describe the output structure, data range, or any edge cases. For a read-only calculation tool, this is minimal but not misleading.
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 a single, well-structured sentence that front-loads the core function (EMA calculation) and includes key parameters. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema, the description gives a high-level overview but does not specify the exact return format (e.g., list of values with timestamps) or the number of data points. It is adequate for a simple indicator but lacks completeness for an agent to fully anticipate the output.
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?
Schema description coverage is 100%, so baseline is 3. The description mentions 'bar unit, period, and calculation basis' which loosely corresponds to interval, period, and price_field, but adds no additional detail beyond the schema.
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 that the tool calculates the exponential moving average (EMA) of a stock and returns an EMA time series based on candle data. This specific verb and resource distinguish it from other technical indicator tools like RSI or MACD.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for computing EMA from candle data but does not explicitly mention when to use it over alternatives (e.g., other indicators) or any exclusions. No reference to specific use cases or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It indicates a read operation via '조회' and adds useful context about market segmentation and account specificity. However, it does not disclose potential side effects, permission requirements, error handling, or return format, leaving some gaps for a tool with no annotation support.
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 a single, concise sentence that is front-loaded with the key action and resource. It contains no filler or redundant phrases, and every word contributes to understanding the tool's function.
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?
The tool is simple with one parameter and no output schema. The description conveys the purpose, the specific market breakdown, and the account scope. While it does not detail the exact response structure, for a query-type tool with this low complexity, the description provides sufficient context for an agent to use it correctly. Minor gap: the phrase '현재 계좌' could be clarified as 'the specified account'.
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?
Schema coverage is 100%, with the parameter 'account_seq' already described as the account identifier from get_accounts. The tool description does not add extra semantic meaning beyond the schema; it only restates that it applies to the current account, which aligns with the parameter but is not more informative. Baseline 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 the specific verb '조회합니다' (retrieves) and clearly identifies the resource: commission rates (매매 수수료율) for the account, segmented by domestic/US markets. This clearly distinguishes it from sibling tools like get_holdings or get_orders, which address different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when commission rate information is needed, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites (e.g., having an account_seq). There is no exclusion or comparison with other tools, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the calculation involves comparing OBV with a signal line (EMA) and returns trend direction, but does not elaborate on edge cases, exact computation details, or interpretation of the trend direction. This is moderate transparency.
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 two sentences, immediately states the core function (calculates OBV), and then explains the comparison with the signal line. Every sentence adds value with no fluff or repetition.
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 simple technical indicator with no output schema, the description sufficiently covers purpose and key behavior. It mentions the comparison with signal line and the output (trend direction). Minor gaps like exact return format or default signal_period are covered by the schema, so overall it is complete enough for typical use.
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?
Schema description coverage is 100% (all three parameters have descriptions), so the baseline is 3. The description adds context about the signal line (EMA of OBV), but does not explain parameter-specific behaviors beyond what the schema already provides. It neither harms nor significantly augments parameter semantics.
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 calculates OBV and returns a volume-based trend direction by comparing with a signal line (EMA of OBV). It names a specific indicator and its purpose, distinguishing it from sibling indicators like get_volume_ma or get_ema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for volume-based trend analysis but does not explicitly state when to prefer this tool over alternatives such as get_volume_ma or get_macd. No exclusions or comparisons are provided, so usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral safety. It uses the verb '조회합니다' (retrieve/inquire), which implies a read-only operation. It also enumerates the types of warnings covered, giving content context. However, it does not disclose return format, whether it supports both KR and US stocks (despite the AAPL example), or any rate limits/permissions.
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 a single, front-loaded Korean sentence that immediately states the resource and warning types. There is no fluff or repetition, making it efficient and easy to parse for an agent.
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 simple one-parameter read tool, the description explains the key content (types of cautions), which is the main context an agent needs. It does not specify the return structure (list vs. object) or field names, but the absence of an output schema and the straightforward nature of the tool mitigate this. Some additional detail about the output shape or scope would improve completeness.
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 covers 100% of the parameter with a clear description and example, so the baseline is 3. The tool description does not add extra semantic meaning beyond the schema; it only explains the tool's overall purpose. Since the schema already documents 'symbol' adequately, the description provides no additional parameter-level value.
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 retrieves buy cautions for a stock, listing specific warning types (delisting trading, short-term overheating, investment warning/risk, VI activation, subscription rights). This specific verb+resource combination distinguishes it from all sibling tools, none of which mention warnings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose is self-evident as a read-only query for stock warnings, and no sibling tool covers this domain, implying it is the go-to for caution information. However, the description does not explicitly state when to use it over alternatives (e.g., before placing a buy order) nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the data source is local storage ('로컬에 저장된') and the content type (AI trade rationale/indicators), but it does not explicitly state that the operation is read-only, how results are ordered, or whether the log is strictly append-only. The 'get' prefix implies read-only, but this is not fully explicit.
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 two concise sentences. The first sentence front-loads the core purpose (query locally stored AI trade history), and the second adds useful context about its strategic use. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 optional parameters, no annotations, and no output schema. The description explains the purpose and general content (trade rationale/indicator state), but it does not describe the return shape, default sort order, or clarify how this differs from get_trades. Given the lack of output schema and the close sibling, the description is adequate but leaves gaps about expected return data and edge cases.
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 input schema provides 100% parameter description coverage, including filters for side, limit, symbol, and date range. The description adds only the conceptual context of '과거' (past) and '근거·지표 상태' (rationale/indicator status), which does not materially extend the parameter meanings already present in the schema. Baseline 3 applies.
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 ('조회합니다' - retrieves) and a clear resource ('AI 매매 이력' - AI trading history). It distinguishes itself from sibling tools like get_trades and get_orders by emphasizing '로컬에 저장된' (stored locally) and '근거·지표 상태' (rationale/indicator status), indicating this is a log of AI decision context rather than raw trade executions.
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 second sentence explicitly explains when to use the tool: to understand past trading rationale and indicator states for current strategy decisions. This provides clear usage context, though it does not explicitly mention when not to use it or point to alternatives like get_trades for broker-executed trade history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses environment variable usage and no parameters, but does not mention what happens on failure, whether the old token is invalidated, or what the response includes. For a state-changing auth operation, this is insufficient behavioral disclosure.
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 two short sentences, front-loads the purpose, and includes only essential information. No waste or redundancy.
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 very simple tool with zero parameters and no output schema, the description covers the core action and invocation method. However, it lacks mention of return value or error behavior, which is a minor gap given the tool's simplicity.
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?
The schema has zero parameters, and the description clearly states no parameters are needed while providing the exact environment variable names (TOSSINVEST_API_KEY, TOSSINVEST_SECRET_KEY) and their client_id/client_secret mapping. This adds meaningful invocation context beyond the empty schema.
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?
Description states a specific action ('reissue access token') and the resource (token) using environment variables, clearly distinguishing it from sibling tools that handle market data or orders. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('재발급' means reissue, so the token already exists) and explicitly states no parameters are needed, but it does not mention when to use it versus alternatives or any prerequisite conditions such as token expiration. Context is clear but not explicit about exclusions or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool writes to a local file and is called after order execution, which implies a side effect. However, it does not disclose potential failures, whether it overwrites existing logs, or any permissions needed. Acceptable but limited for a write operation with zero annotation support.
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 two sentences, front-loaded with the core purpose and includes an essential usage instruction. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, nested objects, and no output schema, the description is somewhat minimal. It explains when to call it and what it does, but does not clarify the relationship with order_id (which is optional but logically required), nor does it mention return values or error behavior. This is a moderate gap for such a parameter-heavy tool.
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?
Schema coverage is 100%, so baseline is 3. The description adds minimal extra context by referring to '근거·지표 스냅샷' (rationale/indicator snapshot), which hints at the rationale and indicators parameters, but it does not meaningfully expand beyond what the schema already provides. It is functional but not additive.
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 records a rationale and indicator snapshot to a local file after trade execution, using a specific verb ('기록합니다') and resource ('로컬 파일'). It also distinguishes itself from siblings by explicitly tying to create_order and noting it logs AI trading history, differentiating from read-only get_trade_log.
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?
It explicitly states when to use the tool: 'create_order 호출 후 반드시 호출해' (must be called after create_order). This gives clear usage timing, though it does not mention alternatives or exclusions. The instruction to call it as a mandatory follow-up is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It explains the interpretation of ADX values but does not specify output format, data source, limitations (e.g., insufficient data), or any side effects. For a simple calculation tool, this is adequate but not rich.
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 two concise, front-loaded sentences. The first states the core action, the second provides interpretation and usage context. No wasted words.
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?
Given the simplicity of the tool and lack of output schema, the description provides sufficient context for an agent to infer the output (ADX and DI values) and understand its application. It lacks an explicit return format, but the interpretation thresholds suggest the available metrics, making it fairly complete.
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?
Schema description coverage is 100%, so the baseline is 3. The tool description adds no extra meaning to the parameters (period, symbol, interval) beyond what the schema already provides, such as default period 14 and interval enums.
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 it calculates the ADX (Average Directional Index) for a stock, using a specific verb ('계산합니다') and resource ('종목의 ADX'). It also provides interpretation thresholds (ADX≥25, +DI>-DI), which distinguishes it from other indicator tools like get_rsi or get_macd.
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 a clear context for use: '추세/횡보 판별로 전략 전환에 활용됩니다' (used for trend/ranging discrimination to switch strategies). This implies when to use the tool, but it does not explicitly mention alternatives or exclusions compared to sibling tools, so it falls 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.
Behavior3/5
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 the use of Wilder smoothing, which is an algorithmic detail. However, it does not mention whether the tool returns a single value or a series, nor any required permissions or side effects. For a pure calculation tool, the lack of side effects is implied but not explicitly stated.
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 two short sentences, front-loaded with the core action and method, then a practical application. Every sentence earns its place with no redundancy or filler.
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?
Given the tool's simplicity and full schema coverage, the description conveys essential context: what is calculated, how, and why. However, there is no output schema, and the description does not mention the format or shape of the returned data, which is a minor gap for a technical indicator tool.
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?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level detail beyond what the schema already provides (e.g., symbol format, interval options, period default). It reinforces that the tool calculates ATR but does not elaborate on parameter behavior.
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 'Calculates the ATR (Average True Range) of a stock using Wilder smoothing', which is a specific verb and resource. It distinguishes itself from sibling indicator tools by explicitly naming the calculation method and its purpose (volatility measurement, position sizing, and stop-loss distance).
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 provides clear usage context by stating it is used for volatility measurement, position sizing, and setting stop-loss distances. It does not explicitly contrast with sibling indicators like RSI or MACD, but the practical use cases are enough to guide an agent on 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does not declare side effects, but for a calculation tool this is less critical. It transparently explains the output details, including the unusual 'future cloud prediction for displacement period' behavior, which goes beyond a simple 'calculate' statement. However, it omits any note about being read-only, though that is inferred from the context.
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 two concise sentences, front-loaded with the primary purpose and followed by a list of returned components. No redundant information; every sentence earns its place.
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 6-parameter tool with no output schema, the description is fairly complete. It names all output components and even the future prediction feature. It does not specify return formats, but the output schema is absent, and the description gives a clear picture of what is returned. Slight gap: it doesn't mention how the cloud direction is represented, but the overall completeness is high.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds slight context by mentioning that displacement relates to future cloud prediction, but it does not explain how the other parameters affect the output. The schema already documents each parameter clearly, so the description adds marginal value.
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 calculates the Ichimoku chart for a stock and lists the specific components (conversion line, base line, leading spans, lagging span, cloud direction, and future cloud prediction). This specific verb+resource clearly distinguishes it from sibling technical indicators like RSI, MACD, and Bollinger Bands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an agent needs Ichimoku data, but it does not explicitly state when to use this over other indicators or provide exclusion criteria. It provides no alternatives or when-not-to-use guidance, so it meets only the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return contents, including the signal score, which is useful. Yet it does not mention any potential limitations, rate limits, computation details, or error behavior, leaving gaps in behavioral transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, then a concise list of outputs and a use case. Every sentence adds value, and there is no redundant or filler content.
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?
The description adequately covers the tool's purpose, output contents, and intended use case, which is sufficient for a simple 2-parameter tool with no output schema. It could be more complete by explaining how the signal score is calculated or what time range is covered, but it is reasonably complete.
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?
Schema description coverage is 100% for both parameters, with symbol example and interval enum, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema, such as how interval affects the returned indicators.
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 it queries major technical indicators at once and lists them (current price, RSI, MACD, Bollinger Bands, ADX, ATR, Stochastic, EMA20/60, Volume MA, signal score). This specific verb+resource structure distinguishes it from sibling tools that fetch individual indicators like get_rsi or get_macd.
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?
It explicitly notes suitability for AI automated trading to minimize analysis call count, giving clear contextual guidance on when to use. However, it does not name alternatives directly or provide when-not-to-use conditions, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral transparency. It discloses that the tool returns session-wise information and covers three business days, which is useful. However, it omits details such as timezone, holiday handling, authentication requirements, or exact return format, which are relevant for a market calendar tool.
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 two concise, front-loaded sentences. The first sentence states purpose, and the second details session and day coverage. No redundant information or filler words are present.
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 simple tool with one optional parameter and no output schema, the description covers the key points: US market, session types, and 3-day range. It is reasonably complete, though it could mention timezone or holiday behavior to be fully self-contained, but these are not critical for a basic calendar query.
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 single parameter 'date' is fully described in the schema with format (YYYY-MM-DD), local US date, and default behavior (today if omitted). The tool description adds no extra parameter semantics beyond this, so the high schema coverage (100%) leads to the baseline score of 3.
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's verb ('조회합니다' = queries) and resource ('미국 시장의 장 운영 시간' = US market trading hours). It further specifies the output breakdown by session (day/pre/regular/after) and the 3-business-day coverage, distinguishing it from the sibling 'get_kr_market_calendar'.
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 provides clear context: it is for US market hours, which implies use when US market calendar data is needed. However, it does not explicitly mention alternatives or when not to use it, such as a direct note to use 'get_kr_market_calendar' for Korean market hours, leaving this inference to the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states the core mutation (price/quantity correction) and market restrictions, but does not disclose side effects, reversibility, permission requirements, or confirmation behavior. This is adequate but shallow.
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 two sentences, front-loaded with the primary action and immediately followed by an important market constraint. There is no redundant or irrelevant information.
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?
The description covers the core purpose and market-specific rules, and the schema provides detailed parameter semantics including the confirmation flag. For a mutation tool with no output schema, it is mostly complete, though it does not specify return values or error behavior.
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 input schema already provides 100% coverage with descriptive text for all 6 parameters. The description's mention of price/quantity and market-specific applicability does not add significant semantic value beyond the schema, so baseline 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 the specific verb '정정합니다' (corrects/modifies) and identifies the resource as '기존 주문' (existing order). It clearly distinguishes from sibling tools like create_order and cancel_order by focusing on modification, and adds market-specific scope (domestic vs US stocks).
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 provides clear context for when to use this tool—when modifying an existing order—and specifies market-based constraints. However, it does not explicitly compare to alternative tools such as cancel_order or create_order, so guidance on alternatives is not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It adds some context by explaining that the response contains accountSeq and how to use it downstream. However, it does not mention authentication requirements, rate limits, pagination, or error cases, leaving gaps for a simple 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every sentence earns its place. The second sentence provides a critical cross-API integration detail without unnecessary fluff.
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 zero-parameter list tool with no output schema, the description adequately covers the purpose and the key response field (accountSeq) for downstream use. It does not explain the full response structure, but this is likely acceptable given the simplicity of the tool and the clear integration guidance provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is complete (100% coverage). The description adds value by explaining that the response's accountSeq is used as a parameter in other APIs, but since there are no parameters to document, the baseline of 4 for zero-parameter tools 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 retrieves the user's account list, using specific verb '조회합니다' (retrieve) and resource '계좌 목록' (account list). It also distinguishes itself from sibling tools by noting the accountSeq usage for other account-related APIs, which is unique to this tool.
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 usage context: use this tool to get the user's accounts, and then use the returned accountSeq as the account_seq parameter in other account-related APIs. It does not explicitly mention when not to use or name alternatives, but there are no direct alternatives for listing accounts among siblings, so this is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool returns three business days (previous/current/next) and that it operates in an integrated KRX+NXT mode, which adds useful context. However, it does not mention holidays, return format, or timezone behavior, but for a simple calendar lookup the disclosed scope is reasonably sufficient.
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 a single, front-loaded sentence that directly states the purpose and output scope. There is zero wasted text, and all necessary information is conveyed efficiently.
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 low-complexity tool with one optional parameter and no output schema, the description adequately explains both the purpose and the returned data scope. It could be slightly more explicit about the exact structure of '장 운영 시간' data, but the guidance is sufficient for an agent to select and invoke the tool correctly.
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 input schema already has 100% coverage for the single optional 'date' parameter with its own description, so the tool description adds little beyond implying the date is a reference point ('조회 기준일'). This meets the baseline of 3 for high schema coverage, as the schema does the heavy lifting.
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 a specific verb ('조회' meaning query/retrieve), a specific resource ('국내 시장(KRX+NXT 통합 모드)의 장 운영 시간'), and the exact output scope (previous/current/next business day). It is immediately distinguishable from the sibling 'get_us_market_calendar' by explicitly naming the KRX+NXT integrated domestic market.
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 clearly implies this tool is for querying domestic Korean market hours, while the sibling 'get_us_market_calendar' handles the US market. Although it does not explicitly say 'use this instead of get_us_market_calendar', the KRX+NXT qualifier provides clear context for when this tool applies, just without an explicit exclusion statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The term '조회' implies a read-only operation, and the statement about all statuses adds a key behavioral trait. It does not disclose return format or error behavior, but for a simple read operation this is sufficient.
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 two concise sentences, front-loaded with the primary action and followed by the status flexibility note. Every word earns its place with no repetition or filler.
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 simple get-by-ID tool with two well-described parameters and no output schema, the description adequately conveys the core function and an important behavioral nuance (all statuses). It lacks an explicit return structure description, but 'detailed information' is reasonably clear for a common lookup pattern.
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?
Schema description coverage is 100%, so parameters are already documented well: order_id references create_order response and account_seq references get_accounts. The tool description itself adds no extra parameter meaning beyond this, so baseline 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 retrieves detailed information for a specific order, using the verb '조회합니다' (retrieves). It explicitly distinguishes from sibling 'get_orders' by targeting a single order ('특정 주문') rather than a list, making its purpose unambiguous.
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 provides useful context that all order statuses are queryable, which helps decide when to use this tool. Parameter descriptions in the schema additionally reference prerequisites (create_order for orderId, get_accounts for accountSeq), guiding the agent on required prior calls. However, it does not explicitly mention alternatives like get_orders for listing or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full burden of behavioral disclosure. It discloses the critical behavior that US stocks return null, and implies that it returns both upper and lower limits. This goes beyond mere tautology or schema repetition, offering meaningful insight into the tool's operation, though it does not detail the exact return structure or error behavior.
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 consists of exactly two clear sentences with no redundancy. It front-loads the purpose and then adds the essential US-stock exception. Every word earns its place, making it highly efficient and skimmable.
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 simple one-parameter read tool, the description is largely complete: it states the main function and the key exception. However, since there is no output schema, the description could have explicitly mentioned the return format (e.g., two numbers in an object). The US null note helps but leaves some ambiguity about how values are presented. Overall, it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the 'symbol' parameter with examples (005930, AAPL), achieving 100% coverage. The description adds value by explaining that US symbols will cause the tool to return null, directly linking the parameter value to a behavioral outcome. This enriches the parameter's semantics beyond the schema's basic type and examples.
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 a specific action ('조회합니다' - retrieves) and specific resource ('당일 상한가 및 하한가' - today's upper/lower limit prices). This distinguishes it from sibling tools like get_prices or get_candles, which serve different purposes. The statement about US stocks returning null adds a unique behavioral distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when price limit information is needed, and the US stock null caveat provides a conditional context. However, it does not explicitly name alternatives (e.g., get_prices) or state when not to use this tool, leaving the agent to infer the appropriate use case from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the transparency burden. It discloses the batch size limit (max 200) and the comma-separated input format, and the read-only nature is implied by '조회' (retrieve). It does not mention error behavior or response structure, but for a simple lookup this is adequate.
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 two sentences, front-loaded with the primary purpose and immediately followed by the key constraint. Every word earns its place, with no redundant filler.
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-only tool with no output schema and no annotations, the description covers the core functionality, the parameter format, and a limitation. It could mention response fields explicitly or error cases, but given the low complexity, it is sufficiently complete.
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?
Schema coverage is 100%, so the schema already documents the symbols parameter fully. The description repeats the comma-separated and max 200 details without adding new semantic meaning, which is the baseline for high schema coverage.
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 retrieves basic stock information (name, market, currency, listing status, etc.) with a specific verb '조회' (retrieve) and a well-defined resource. This distinguishes it from sibling tools like get_prices, get_candles, or technical indicators, which focus on price or derived data.
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 implies the tool is for basic stock metadata lookups, and the batch limit of 200 gives usage context. It does not explicitly name alternatives or state when not to use it, but the sibling tool names make the division of labor reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![tossinvest-mcp MCP server](https://glama.ai/mcp/servers/ryum91/tossinvest-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ryum91/tossinvest-mcp)

Score Badge

Copy to your README.md:

[![tossinvest-mcp MCP server](https://glama.ai/mcp/servers/ryum91/tossinvest-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ryum91/tossinvest-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/ryum91/tossinvest-mcp'

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