Toss Invest MCP

by takeachangs

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool has a clearly distinct purpose: market data (orderbook, prices, trades, limits, candles), reference info (stocks, warnings, exchange rate, calendars), account info (accounts, holdings, orders, buying power, sellable quantity, commissions), and order actions (create/modify/cancel). There is no overlap or ambiguity between tools.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern: get_* for queries, and create_order/modify_order/cancel_order for order actions. This makes the API predictable and easy to navigate.
Tool Count3/5
20 tools falls in the 16-25 range, which is considered heavy. While each tool earns its place and serves a distinct function, the overall count is on the high side and might feel overwhelming for a single server.
Completeness5/5
The tool surface covers the full lifecycle for trading: market data, reference info, account discovery, holdings, order management, buying power, sellable quantity, and commissions. There are no obvious gaps or dead ends for the core investing workflow.
Average 4.1/5 across 20 of 20 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the safety profile is covered. The description adds that the quantity is 'in your account' and per symbol, providing minor scoping context. It does not disclose edge cases, permissions, or what happens if the symbol has no sellable quantity, but this is acceptable given the annotations provide the key behavioral trait.
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 redundant text. The Korean translation adds clarity for non-English users without bloating the content. Every word contributes to the core purpose.
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-only tool, and the output schema covers return value structure. However, it lacks context about account_seq and when to use this tool instead of siblings like get_holdings or get_buying_power. The presence of annotations and output schema reduces the burden, so this is not a critical gap, but the description does not fully complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), and the description only implicitly clarifies 'symbol' by mentioning 'for a symbol'. It does not explain the 'account_seq' parameter, its optionality, or when it should be used. The description fails to compensate for the lack of schema descriptions, leaving account_seq ambiguous.
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 gets the sellable quantity for a symbol in the user's account, using a specific verb ('Get') and resource ('sellable quantity'). It does not explicitly differentiate from sibling tools like get_holdings, but the purpose is unambiguous enough that it's easily distinguished.
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 offers no guidance on when to use this tool versus alternatives. It does not mention scenarios such as placing a sell order or checking available quantity before trading, nor does it contrast with get_holdings or get_buying_power. No exclusions or alternative references 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?
The annotations already disclose that the tool is non-read-only, destructive, and interacts with the open world. The description adds the prerequisite that trading must be enabled, which is useful context, but it does not disclose potential failure modes (e.g., order already filled), the irreversibility of cancellation, or any rate limits. While it avoids contradicting the annotations, the added behavioral context is minimal.
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 sentence with two clear statements: what the tool does and a required environment variable. It is concise, front-loaded, and contains 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?
Given that this is a destructive action with real-world implications (openWorldHint=true), the description is too sparse. It omits details about error handling, order state checks, and the effect of cancellation. While an output schema exists, the description should still provide sufficient context for safe usage, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides two parameters (order_id and account_seq) with no descriptions, and the tool description does not explain their meaning or usage. At 0% schema description coverage, the description should compensate, but it fails to clarify what order_id refers to or when account_seq is required, leaving the agent uncertain about invocation.
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 'Cancel' and identifies the resource as 'an open order,' clearly distinguishing this from sibling tools like create_order, modify_order, and get_order. It succinctly states the tool's function without ambiguity.
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 states a prerequisite (TOSS_ENABLE_TRADING=true) but does not provide any guidance on when to use this tool over alternatives, nor any exclusions or preconditions beyond the flag. The use case is implied by the name and purpose, but no explicit direction 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds value by mentioning 'reference' rate and optional historical date_time, but does not disclose additional behavior such as error handling or rate-source details.
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 purpose, and contains no filler. 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 simple read-only tool with annotations and an output schema, the description covers the core purpose and the only optional parameter. Minor gaps in usage guidance and explicit base/quote semantics exist, but the overall context is sufficient for correct invocation.
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 0%, so the description must compensate. It explains date_time as an optional ISO 8601 timestamp for historical rates and clarifies base/quote via example, but it does not explicitly define the base/quote relationship or currency enum constraints beyond what the schema already provides.
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 gets 'the reference exchange rate between two currencies' with a concrete example (base USD / quote KRW). This is a specific verb+resource, though it does not explicitly differentiate from sibling tools like get_prices.
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 about when to prefer this tool over alternatives, nor any exclusions or 'use instead' notes. The description only states what the tool does, leaving usage decisions to inference.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the specific data returned (upper/lower limits) but does not disclose additional behavioral traits such as format, edge cases, or authentication needs. With annotations covering the safety profile, the added value is minimal but 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, focused sentence with no unnecessary words. It is front-loaded with the verb and resource, making it highly efficient.
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 low complexity (one parameter, read-only, no nested objects) and the presence of an output schema, the description is adequately complete. It specifies the core purpose and scope, though it could mention edge cases or units, which are likely covered by the output schema.
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 0%, meaning the schema does not describe the 'symbol' parameter. The description clarifies it is for a symbol, but this is largely redundant with the parameter name. It adds some context but does not fully compensate for the lack of schema-level documentation.
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 action ('Get') and the resource ('upper/lower price limits') for a specific symbol. It distinguishes this tool from siblings like get_prices or get_orderbook by focusing on price limits specifically.
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 you need price limits for a symbol, but it does not explicitly mention alternatives or when not to use it. The purpose is clear enough that an agent can infer the appropriate context, but there is no explicit 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds contextual detail that rates are market-specific and account-specific, which is useful. It does not describe behavior like defaulting to a primary account, but with annotations present, 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 a single sentence, front-loaded with the verb and no extraneous words. It is ideally concise for a simple getter tool.
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 one optional parameter, clear annotations, and an output schema, the description covers the core purpose. However, it lacks parameter semantics and any note on how markets are selected, but given the tool's simplicity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% as the description does not mention account_seq. The schema provides type and default, but the description leaves ambiguity about what account_seq represents and how null is handled. The name implies an account identifier, but without explicit semantics, this is a gap.
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 verb 'Get' and the resource 'trading commission/fee rates', with scope 'by market for your account'. It is distinct from sibling tools like get_prices or get_orderbook, which serve 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 for retrieving commission rates, but provides no explicit when-to-use guidance or alternatives. It does not mention when account_seq should be provided or omitted, leaving the usage context implicit.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read. The description adds useful context by specifying 'any status' and 'including partial-execution history', which are behavioral traits beyond the annotations. It does not cover pagination or return format, but an output schema exists.
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 sentence of 13 words, front-loaded with the main action, and every word adds value. No filler 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?
With an output schema present, return values are covered. The description is adequate for a simple read tool, but the lack of parameter documentation (especially account_seq) leaves a slight gap. Still, for a single-order fetch with read-only annotations, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It only implies order_id is the order identifier via 'Get full detail for one order', but account_seq is completely unexplained, and no format or optionality hints are provided.
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 fetches full detail for a single order, with the verb 'Get' and resource 'order'. It explicitly mentions 'any status' and 'partial-execution history', which distinguishes it from sibling tools like get_orders (likely a list) and get_trades.
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 retrieving one specific order, but it does not explicitly differentiate from alternatives like get_orders or mention when not to use it. There is no clear statement of when to prefer this tool over others.
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?
Annotations already mark the tool as read-only (readOnlyHint=true) and non-destructive (destructiveHint=false). The description adds behavioral context by enumerating the types of warnings returned, which helps the agent expect the data content. It does not discuss rate limits or data freshness, but annotations lower the bar for 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 a single concise sentence that front-loads the action and object, with a parenthetical list of warning types. Every word earns its place; no 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?
The tool has a simple one-parameter schema, an output schema exists, and annotations provide safety info. The description adequately covers the tool's purpose and scope, listing representative warning types. It could mention the market context (Korea) but the Korean terms imply it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'symbol' with no description (coverage 0%). The description only mentions 'for a symbol', giving no type, format, or examples. It adds minimal meaning beyond 'symbol' in 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 uses the verb 'Get' with a specific resource 'purchase warnings/cautions' and specifies the input 'for a symbol'. It lists concrete types (정리매매, 단기과열, 투자경고/위험, VI, 신주인수권 etc.), making it distinct from siblings like get_prices or get_trades.
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 retrieving warning/caution status for a given symbol, but does not provide explicit when-to-use guidance vs alternatives (e.g., when checking listing eligibility or order constraints). No exclusions or alternative tool mentions are given.
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?
Beyond the readOnlyHint annotation, the description adds the count limit ('count: max 50') and clarifies 'executed trades' (체결 내역), indicating it excludes pending orders. However, it does not specify the time window for 'recent' or pagination 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 a single sentence plus a fragment, front-loaded with the primary action. It is concise and every word adds value.
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 presence of an output schema and annotations, the description is reasonably complete for a simple read-only tool. It mentions the key constraint (count max 50), but 'recent' is vague and could benefit from a time range definition. Overall adequate.
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 has 0% description coverage. The description adds a constraint for `count` (max 50) but does not explain that `count` is optional or what `symbol` should look like. This partially compensates for the schema, but leaves some burden on the agent.
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 the tool retrieves recent executed trades for a symbol, using both English and Korean (체결 내역) to clarify executed trades, distinguishing it from get_orders (order status) and get_candles (price history).
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 no explicit guidance on when to use this tool versus alternatives like get_orders. The purpose is clear but no exclusion criteria or alternative references are given, so it falls under implied usage.
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?
Annotations already declare the tool as read-only and non-destructive, so the bar is lower. The description adds that the tool returns bid/ask orderbook data and specifies symbol formats, but it does not disclose depth, aggregation, or rate limits. Given the annotations cover safety, 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 sentences: one stating the purpose and one clarifying the parameter format. No wasted words; front-loaded with the core action and resource.
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 an output schema available, so the description need not explain return values. It covers the essential purpose and parameter format. However, it could add context such as market availability or orderbook depth, but these are not critical given the output schema.
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 input schema has 0% description coverage, so the description carries the full burden for parameter meaning. It clearly explains the 'symbol' parameter with specific formats and examples (KRX 6-digit or US ticker), fully compensating for the schema's lack of documentation. This exceeds the baseline for low 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 it gets the bid/ask orderbook for a given symbol, using a specific verb+resource. It distinguishes itself from sibling tools like get_prices and get_trades by naming the exact data type. The symbol format guidance further clarifies the tool's scope.
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 retrieving orderbook data but does not explicitly state when to use this tool over alternatives such as get_prices or get_trades. It offers no exclusions or alternative tool mentions, but the tool name and market data context provide some implicit 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?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds a meaningful behavioral detail: 'excludes margin', clarifying the precise nature of the buying power returned. This goes beyond the annotations without contradicting them.
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?
A single sentence, front-loaded with the core action and object. Every phrase earns its place, including the Korean translation and the margin exclusion. 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?
The tool is a simple read-only getter with two parameters, one required and one optional. The description, combined with the existing output schema and annotations, covers the essential behavior. It could benefit from a note about account_seq, but the schema already provides the type and default, so the description remains sufficient.
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 0%, so the description should compensate. It clarifies that the currency parameter accepts KRW or USD, which is already in the enum, and adds the 'cash' context. However, it does not explain the optional account_seq parameter, leaving the agent to infer its purpose from the schema alone.
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 ('Get') and resource ('cash buying power') with clear scope (per currency). It explicitly excludes margin, which distinguishes it from related tools like get_sellable_quantity or margin-related queries. The Korean gloss adds further precision.
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 states the tool is for retrieving cash buying power for KRW or USD, setting a clear usage context. It does not name alternative tools or explicitly state when not to use it, but the 'excludes margin' note and the currency scope provide enough guidance for selection among siblings.
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?
Annotations already declare readOnly=true and destructive=false, so no contradiction. The description adds operational context: a limit of 200 symbols and the comma-separated format with an example. This goes beyond what annotations provide, though it does not cover error handling or data latency.
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 sentences, direct, and no filler. The purpose is front-loaded, followed by parameter details. 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 simple one-parameter lookup tool with an output schema, the description is nearly complete: it names the returned fields and the input constraints. A minor gap is the lack of explicit 'when to use' relative to sibling tools, but the purpose is clear enough.
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 provides only a type and no description, so the 0% schema coverage puts the burden on the description. The description explains the expected comma-separated format, provides an example, and specifies the maximum number of symbols, which is essential for using the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'reference info' and enumerates the data fields returned, distinguishing it from sibling tools like get_prices or get_orderbook by the nature of the data (static reference versus 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need reference data), but does not explicitly state exclusions or mention alternative tools for real-time data, such as 'for current prices, use get_prices.' It relies on inference rather than explicit 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?
Annotations already indicate mutation (readOnlyHint=false) and destructive potential (destructiveHint=true). The description adds value by requiring TOSS_ENABLE_TRADING=true and detailing critical constraints (quantity required for KR, omitted for US; price required for LIMIT, omitted for MARKET). It does not disclose side effects like whether partial modifications are supported or if confirm_high_value_order triggers extra confirmation, but the bar is lowered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core purpose, the second gives a key prerequisite, and the final lines concisely encode market-specific rules. Every sentence adds necessary context without fluff, achieving high information density in under 50 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?
Despite having 6 parameters and no schema descriptions, the description covers the most critical usage constraints (market differences, order type rules, trading flag). It is slightly incomplete around account_seq and confirm_high_value_order, and the presence of an output schema reduces the need to explain return values. Overall, it provides enough context to use the tool correctly in most 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?
Schema description coverage is 0%, so the description must compensate. It adds meaning for order_type (LIMIT vs MARKET), price (required for LIMIT, omitted for MARKET), and quantity (KR required, US not supported), and order_id is implied as the open order's ID. However, account_seq and confirm_high_value_order are not explained at all, leaving 2 of 6 parameters semantically opaque.
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 'Modify an open order's price/quantity' with a specific verb and resource, and the scope (price/quantity) distinguishes it from create_order and cancel_order. The focus on open orders and explicit field modifications makes the 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 clear context for when to use the tool: modifying open orders, with explicit prerequisites (TOSS_ENABLE_TRADING=true) and market-specific rules (KR vs US stocks, LIMIT vs MARKET). However, it does not explicitly contrast with alternatives like cancel_order or mention scenarios where modification is inappropriate (e.g., already filled orders), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read operation. The description adds behavioral detail by specifying the return content (per-symbol P&L, account summary) and the account_seq default behavior, which exceeds what annotations alone provide.
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 primary purpose and then detailing parameters. No filler or redundant 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?
Given the tool's simplicity (2 optional params, output schema present, annotations available), the description covers the key aspects: what it returns, parameter defaults, and optional filtering. It does not explain return values, but the output schema handles that. A minor gap is the lack of clarification on how the account summary interacts with the symbol filter, though not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining both parameters: account_seq defaults to TOSS_ACCOUNT_SEQ when unset, and symbol is an optional single-holding filter. This adds clear meaning beyond the schema's type/default information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets holdings/positions with per-symbol P&L and an account summary. The verb 'Get' and specific resource 'holdings/positions' distinguish it from sibling tools like get_accounts, get_orders, and get_buying_power.
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 parameter context (account_seq default, symbol optional filter) but does not explicitly state when to use this tool versus alternatives. Selection is implied by the name and output description, but there is no exclusion wording or reference to sibling 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?
Annotations already declare this as a safe read-only operation. The description adds the useful constraint of a 200-symbol maximum and the input format, but does not discuss edge cases such as invalid symbols or behavior on exceeding the limit. 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 concise and front-loaded: the first sentence states the core function, and the second line gives the critical parameter format. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with an output schema, the description, annotations, and schema together provide sufficient context. The symbol format, limit, and read-only nature are all covered, and the sibling list clarifies the tool's niche in the broader API.
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?
With 0% schema coverage, the description compensates by explaining that the 'symbols' string is comma-separated and provides concrete examples for both Korean and US markets. This adds essential meaning beyond the bare schema, though it stops short of covering every edge case like spaces or validation rules.
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 clearly states the tool retrieves current prices for up to 200 symbols. The verb 'Get' and resource 'current prices' are specific, and the tool is distinguished from siblings like get_candles, get_trades, and get_orderbook by focusing on the current snapshot.
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?
Provides clear usage context by specifying the comma-separated symbol format and the 200-symbol limit. It does not explicitly contrast with alternative tools for historical data, but the wording 'current prices' implies the appropriate time-sensitive use case.
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?
Annotations already declare readOnlyHint and destructiveHint false. The description adds meaningful behavioral context beyond annotations: pagination via 'nextBefore' (exclusive cursor), count max limit of 200, and the adjusted-price flag. These operational details help the agent understand how the tool behaves during repeated calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose followed by compact parameter explanations. Every sentence adds value; there is no redundancy or filler, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety, the description provides all necessary operational context: interval choices, count constraints, pagination contract, and adjusted-price behavior. It is complete 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains interval ('1m'/'1d'), count (max 200), before (ISO 8601 exclusive cursor, use nextBefore for pagination), and adjusted (수정주가). Only 'symbol' is left undocumented, but it is a standard ticker string that is self-evident.
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 opens with 'Get candlestick chart data' – a specific verb+resource that clearly identifies the tool's function. It distinguishes itself from sibling tools like get_prices and get_trades by explicitly focusing on candlestick data and providing interval options (1m/1d).
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 does not explicitly state when to use this tool over alternatives, nor does it mention exclusions. However, the parameter details and the candlestick focus imply its purpose for charting or historical OHLC data. Usage context is implied but not directly guided.
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?
Annotations already declare the tool read-only and non-destructive, so the description only needs to add context beyond that. It provides the date format and default value, which is useful, but does not disclose other behavioral details such as return structure or timezone, though an output schema exists. This matches the pattern of adding some value without rich behavior 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 a single sentence followed by a brief parameter hint, front-loading the core purpose and adding no extraneous information. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter), the description covers purpose and parameter semantics adequately. Annotations handle safety and open-world behavior, and an output schema exists for return values, making the description complete within its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fully documents the only parameter 'date' by specifying the format 'YYYY-MM-DD' and the default 'today', which the schema does not provide. This is exactly the added value needed.
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 'Get' with the resource 'KRX/NXT market operating calendar,' clearly stating what the tool does. It distinguishes itself from the sibling tool get_us_market_calendar by explicitly naming the Korean exchanges, making the 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 implies usage context by specifying KRX/NXT, which differentiates it from the US market calendar sibling. However, it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria, so it falls short of full 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the date formatting and default, which are parameter semantics rather than behavioral traits. No contradiction or additional behavioral disclosure is needed.
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, front-loaded with the purpose and followed by the parameter clarification. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with an output schema and a single optional parameter that is fully documented in the description, nothing is missing. The US vs Korean market distinction is clear from the name and description, making it complete for agent understanding.
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 one parameter with no description (0% coverage). The description compensates fully by specifying the exact format (YYYY-MM-DD), timezone (US local), and default behavior (today), providing essential meaning 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 the tool gets the US market operating calendar, a specific resource, distinguishing it from the Korean market calendar sibling (get_kr_market_calendar). The verb 'Get' and resource 'US market operating calendar' are explicit 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is for the US market, implying use when US market calendar information is needed. It does not explicitly mention alternatives like get_kr_market_calendar, but the sibling tool list makes the differentiation obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description highlights the real-money nature, environmental prerequisite, idempotency key behavior, and high-value order confirmation. This adds substantial behavioral context beyond what annotations convey.
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 compact and well-structured, using line breaks for distinct rules. Every sentence adds critical information without fluff. It's appropriately sized for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex trading tool with conditional parameters and market-specific rules, the description covers prerequisites, mutual exclusions, formatting, idempotency, and high-value confirmations. The output schema exists, so return values needn't be explained. This is comprehensive given the tool's complexity.
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?
Schema description coverage is 0%, but the description explains several complex parameters in detail: quantity vs order_amount, price formatting rules, time_in_force options, client_order_id constraints, and confirm_high_value_order. It omits trivial params like symbol, side, order_type, and account_seq, which are self-explanatory from the schema, so the compensation is strong but not complete.
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 'Place a REAL-MONEY order', which is a specific verb+resource combination. It distinguishes itself from sibling tools like modify_order and cancel_order by being the tool for creating new orders.
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 and constraints, such as 'Requires TOSS_ENABLE_TRADING=true', 'Provide exactly one of quantity/order_amount', and 'LIMIT requires price; MARKET must omit price'. However, it doesn't explicitly mention when to use alternative tools (e.g., modify_order or cancel_order), though the purpose is unambiguous.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context by explaining the returned accountSeq's role as a header value, and the 'active accounts' qualifier implies filtering. No contradictions, and the added detail is meaningful.
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 sentences with zero waste. The primary action is front-loaded, and the critical usage note follows immediately. Perfectly sized for a simple discovery tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (0 params, no nested objects) and has an output schema, so the description covers the essential context: what it lists, why to call it first, and how to use its result. No gaps are apparent for a discovery tool.
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?
Tool has 0 parameters, so schema coverage is trivially 100%. Baseline is 4. The description adds no parameter details (none needed) but does explain a key output field (accountSeq), providing value 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?
Description uses a specific verb ('List') and resource ('your active accounts'), clearly distinguishing this discovery tool from account-scoped siblings like get_holdings and get_orders. It also adds the crucial role of the returned accountSeq, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Call this first to discover your account(s)', providing clear when-to-use guidance. Since it's a foundational tool, it doesn't need alternatives, but the note about accountSeq being used by all account-scoped tools establishes its context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavioral details beyond annotations: date format KST, order time, limit default/max, cursor/limit only for CLOSED, and OPEN returns all. No contradiction with readOnlyHint.
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 pack significant information; front-loaded with the primary action and status grouping.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description doesn't need return details. It covers the key usage behaviors: status, date filtering, and pagination asymmetry between OPEN and CLOSED. Very complete for a list tool.
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?
With 0% schema description coverage, the description compensates by explaining status, date range, limit/cursor semantics. However, symbol and account_seq are left unexplained, though they are optional and reasonably inferable from names.
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 the tool 'List orders by lifecycle group' and defines the status values, clearly identifying the resource and scope. It is distinguishable from sibling tools like get_order which retrieves a single order.
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?
Provides clear context: date range format, KST, order time, and explicit pagination behavior for CLOSED vs OPEN. Does not explicitly name alternative tools for single-order lookup, but the usage parameters are well-defined.
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:

[![toss-invest-mcp MCP server](https://glama.ai/mcp/servers/takeachangs/toss-invest-mcp/badges/card.svg)](https://glama.ai/mcp/servers/takeachangs/toss-invest-mcp)

Score Badge

Copy to your README.md:

[![toss-invest-mcp MCP server](https://glama.ai/mcp/servers/takeachangs/toss-invest-mcp/badges/score.svg)](https://glama.ai/mcp/servers/takeachangs/toss-invest-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/takeachangs/toss-invest-mcp'

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