kiwoom-mcp-server
Server Quality Checklist
Latest release: v0.52.1
- Disambiguation5/5
Each tool targets a distinct data query, and descriptions explicitly cross-reference related tools to clarify boundaries. Even the many investor-flow tools have unique angles (intraday vs daily vs rank vs specific entity) that prevent confusion.
Naming Consistency5/5All tools follow a consistent get_<domain>_<detail> naming pattern (e.g., get_stock_price, get_account_balance), with only ping and search_stock as exceptions. There are no casing or verb inconsistencies.
Tool Count2/5At 49 tools, the server is far beyond the 25-tool threshold for 'too many.' While the broad scope of the Kiwoom API justifies many endpoints, the sheer number creates significant overhead for an agent to select among them, and several tools could be consolidated.
Completeness4/5The server provides comprehensive read-only coverage of Korean stock market data, including market, sector, ETF, gold, investor flows, short/lending, and account queries. Minor gaps exist (e.g., no order execution, no news) but agents can work around them.
Average 4.4/5 across 43 of 49 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 107 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto 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?
No annotations are provided, so the description must carry behavioral disclosure. It reveals the tool reads historical short selling data and lists the returned fields, but does not mention rate limits, error conditions, data range limits, or confirm it is non-destructive. The source reference (키움 ka10014) adds credibility but not behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose and data details. No redundant words; each sentence adds essential information. The structure is optimal for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and no output schema, the description adequately covers the tool's purpose and data fields. It mentions default period and date customization. However, it does not specify output format (list vs. single record), pagination, or any constraints on date range length, leaving some gaps for a time-series tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, so baseline is 3. The description adds value by explaining the default date range (30 days) and that the tool returns multiple data points per date, which enriches understanding beyond raw schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inquires daily short selling trends for a specific stock, listing specific data fields (closing price, fluctuation rate, volume, short selling volume, ratio, average price). This distinguishes it from siblings like get_stock_lending and get_investor_trend, which cover 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool vs. alternatives (e.g., get_stock_lending). It only mentions the default 30-day period and that dates can be customized, but does not state prerequisites, limitations, or exclusion cases.
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. While it lists output fields, it does not mention whether data is real-time or delayed, error handling for invalid codes, authentication requirements, or rate limits. This is a significant gap for a data retrieval 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. The first sentence covers functionality, the second provides a critical usage hint. Structure is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description provides a good list of return elements (price, change rate, volume, basic indicators, industry/listing date, special status). It is complete enough for an agent to understand what data to expect, though error behavior and real-time status are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description and pattern. The description adds context (domestic stocks/ETFs, ka10001 reference) but does not add substantial 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (조회하다/retrieve), resource (국내 주식/ETF의 현재가, 등락률, 거래량, 기본 지표), and input (6자리 종목코드). It distinguishes itself by mentioning it also shows industry/listing date and special status, which is not covered by siblings like search_stock or get_etf_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells agents to use search_stock if only the stock name is known, providing clear when-to-use vs. when-not-to guidance. It implies this tool is for a single stock code, but does not explicitly exclude other tools like get_stock_quotes for multiple quotes.
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 provided, so the description carries full burden. It mentions internal API codes (ka40002, etc.) but does not explicitly state read-only behavior, authentication needs, or rate limits. Adequate but lacks explicit safety characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the action and APIs used, second gives a usage tip. Front-loaded with essential information, no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description lists the returned fields (tracking index, tax type, price, NAV, discrepancy). Could be improved by specifying output format or structure, but overall sufficient for a simple one-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with pattern and example. The description adds the practical tip about using search_stock but does not add new semantic 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries ETF information including tracking index, tax type, current price, NAV, and discrepancy. It distinguishes itself from siblings like get_etf_returns by specifying multiple data sources and mentions using search_stock for unknown codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using search_stock first if the stock code is unknown, providing a clear alternative. Does not differentiate from get_etf_returns or other ETF-related tools, but the context of 'ETF info' implies its scope.
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 bear the burden. It adds useful context (max 30 stocks, internal code, alert statuses in remarks) but does not explicitly state that the tool is read-only or idempotent, nor mention rate limits or error behaviors. A score of 3 is appropriate given the lack of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and data fields, followed by usage guidance and a note about alert statuses. No redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 1 parameter and no output schema, the description covers the returned fields (price, change, volume, amount, market cap, remarks) and usage context. It could mention error handling or output formatting but is otherwise complete for a batch query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the parameter. The description repeats the parameter constraints (6-digit codes, 1-30 items) and provides an example. This adds no significant value beyond the schema, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries current price, change rate, volume, transaction amount, market cap, and alert statuses for multiple stocks. It distinguishes itself from sibling get_stock_price by explicitly recommending this tool for batch queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this when needing quotes for 2+ stocks and to avoid repeated calls to get_stock_price. It implies not to use for single stocks but does not explicitly state the alternative, though it is clear enough for an agent.
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 reveals it is a read operation and mentions the 2-month constraint. However, it does not disclose authentication requirements, rate limits, or behavior when no data is found. It adds value but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and return data, second details parameter behavior. No redundancy, perfectly front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description summarizes key output fields (per-stock prices, quantities, profit/loss, totals). It references the API source but does not describe the exact output structure (e.g., list vs object). Mostly complete for a daily journal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description reiterates the same information about base_date (default today, last 2 months). It adds no new meaning 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a daily trading journal for a specific date, listing details like average buy/sell price, quantity, profit/loss, and return rates. It references the specific API (ka10170), distinguishing it from siblings like get_account_holdings or get_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it (for a specific date, defaults to today) and constraints (only within last 2 months). It does not explicitly exclude alternatives, but the context is clear enough for an agent to decide.
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 full burden of behavioral disclosure. It discloses parameter interactions (stock_code overrides market, potential empty results), lists return fields (발동가격, 괴리율, etc.), and identifies the data source (키움 ka10054). It lacks details like sorting/pagination or whether the data is real-time, but for a lookup tool, it provides substantial 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded. The first sentence clearly states the purpose, and the following dash-separated clauses compactly summarize parameter options and special behavior. It is concise yet informative, with no filler content, though it is slightly dense due to the parameter enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description does a good job covering the essentials: purpose, parameter defaults, parameter interactions, and return fields. It does not explicitly describe the output format or sorting order, but these are not critical for a simple retrieval tool. The mention of the underlying system (ka10054) adds useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds some semantic value by translating enum values (상승/하락, 정적/동적) and explaining the consequence of stock_code/market mismatch ('종목의 시장과 어긋나면 결과가 비므로'). However, much of the parameter information is already present in the schema descriptions, so the added value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '당일 변동성완화장치(VI)가 발동된 종목을 조회합니다' (retrieve stocks that triggered VI today). It specifies the resource (VI-triggered stocks), the verb (조회/retrieve), and lists the key data fields returned (발동가격, 괴리율, 등). This clearly distinguishes it from sibling tools like get_market_movers or get_stock_quotes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: for retrieving VI-triggered stocks. It explains parameter defaults and the precedence rule for stock_code over market, including a practical warning about mismatched markets leading to empty results. However, it does not explicitly mention when not to use it or suggest alternative 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses first call delay (few seconds due to master download) and 12-hour cache, and that caution status appears in notes. Fills the gap left by missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (4 sentences) with key information front-loaded: purpose, when to use, behavioral notes. Slightly verbose with the internal code mention but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with no output schema, description covers input, caching behavior, returned information (code, caution status). Adequate for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and describes the query parameter adequately. Description adds context about scope (KOSPI/KOSDAQ, ETFs/ETNs) but does not significantly enhance parameter understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches stocks by name or code to find stock codes for KOSPI/KOSDAQ including ETF/ETN, referencing internal code. It distinguishes from sibling tools which are data retrieval 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use this tool first when stock code is unknown before passing to other tools. While it doesn't list when not to use, the guidance is clear and contextually sufficient.
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. It discloses that the operation is a retrieve (조회), lists output fields, and notes that no arguments are required. However, it does not explicitly state that it is read-only, mention error conditions, or authentication requirements. Adequate for a simple getter but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. The main action is front-loaded ('조회합니다'), and the detailed field list is appended logically. No wasted words or redundancy with the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is fully complete. It enumerates the exact return fields, identifies the data source (키움 kt00018), and confirms no arguments are needed. No additional context is required for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description explicitly states '인자가 필요 없습니다' (no arguments needed). This goes beyond the baseline for zero-parameter tools, providing clear confirmation and eliminating any ambiguity about invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 holdings list and enumerates the specific fields returned (quantity, average price, current price, valuation amount, profit/loss, return rate, weight). This distinguishes it from sibling tools like get_account_balance, which focus on balance rather than held stocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when holdings are needed but provides no explicit alternative guidance or when-not-to-use conditions. It does not compare with other account-related tools, leaving the agent to infer from 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?
No annotations are provided, so the description carries full burden. It explains the two views and their behavior (e.g., daily shows top net buy/sell by date, streak shows consecutive net buy for N days) and mentions API codes. However, it does not disclose return format, pagination, rate limits, or authentication needs, which are gaps for a data retrieval 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences plus a usage example. All sentences are necessary and front-loaded with key information (purpose, views, example queries). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description covers purpose, views, parameter usage, and market restrictions. It lacks details on return format, but this is partially compensated by the schema. Overall, it is functionally complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds context beyond the schema, such as default values for date (recent trading day) and market (differs by view), and explains how views affect parameter behavior. This adds meaningful guidance for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves stocks heavily bought/sold by foreigners and institutions (specific verb and resource). It specifies two views (daily and streak) and provides usage examples, making the purpose distinct from sibling tools like get_investor_trend or get_market_movers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage examples and clarifies that daily view supports all markets while streak only supports KOSPI/KOSDAQ. This helps the agent choose between views, though it does not explicitly mention when not to use the tool or alternative tools.
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?
No annotations provided, so the description carries full burden. It discloses the source, output structure, and cross-references. While it doesn't mention auth or rate limits, for a read operation this is sufficient and adds value beyond a basic description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence states the purpose, the second adds structural detail and cross-reference. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides essential context about the output format (first row composite, then sectors) and how to use the results. It is complete enough for a simple market index tool, though it omits pagination or limits which are likely unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (market) with enum and description, achieving 100% coverage. The description does not add additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves KOSPI/KOSDAQ composite and sector indices, referencing the source code ka20003. It also explains the output structure (first row composite, subsequent sector indices) and how the code field links to other tools, which distinguishes it from siblings like get_sector_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (for market and sector indices) and hints at a workflow by noting that the code can be used with get_sector_price/get_sector_stocks. It does not explicitly state when not to use or compare with alternatives, but the context is clear enough.
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 this is a read-only query and explicitly says it does not provide order execution functionality, which is important safety context. However, it does not clarify the time range of the executions (e.g., today only vs. all history) or mention pagination/result limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, starting with the core function, then field list, filter options, alternative tools, and a safety note. Every sentence adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a query tool with no output schema, the description provides a solid list of returned fields, filter options, and alternative tools. It misses explicit mention of the time range (today vs. all) and whether results are sorted, but overall it gives enough context for an agent to decide when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with each parameter described (side, order_no, stock_code) including enums and patterns. The description only mentions that these parameters can narrow the query, adding little 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it queries execution (filled order) details for an account, and lists the specific fields returned (order number, stock, buy/sell, order status, quantities, prices, fees/taxes, time). It also distinguishes itself from sibling tools by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides alternative tool recommendations: get_pending_orders for unexecuted orders, get_trading_journal for daily stock aggregation, and get_transactions for period transactions. It also clarifies this tool is read-only and does not execute orders, giving clear usage boundaries.
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. It discloses the read-only nature and lists returned fields. It does not cover rate limits or authentication, but the read-only behavior is sufficient for this type of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and includes only relevant details: fields returned, filter option, and read-only nature. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one optional parameter and no output schema, the description is fairly complete. It explains input, output fields, and behavior. However, it lacks details on response format or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter stock_code. The description reiterates the same information as the schema's description, adding no extra meaning. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves pending order lists from an account, listing specific fields (order number, stock, buy/sell type, etc.) and explicitly mentions it is read-only and does not execute orders. This distinguishes it from siblings like get_account_balance or get_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool is read-only with no order execution, and mentions optional filtering by stock_code. It gives clear context but does not explicitly compare to alternatives or state 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.
- 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. It discloses a behavioral trait: ambiguous sector names return errors with candidate codes, and it references the underlying Kiwoom API codes (ka20004~ka20008/ka20019). It does not cover rate limits or auth, but the disclosed ambiguity handling adds meaningful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the main purpose and embed essential period and sector code details without any fluff. Every sentence earns its place, and it is efficiently structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, period options, and sector code semantics, which is sufficient given the detailed schema. It does not describe the return format, but the tool is a chart retrieval and the schema covers all parameters, so the context is mostly complete. Minor gap: no explicit description of the output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds Korean translations for period values (e.g., '일봉', '주봉') and clarifies that sector_code can be a name or code, but these are largely redundant with the schema. The cross-reference to get_market_index provides modest added value, but not enough to score higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves candle charts for sector indices, with a specific verb ('조회합니다' = retrieves) and resource ('업종 지수의 캔들 차트'). It lists period options and sector code formats, distinguishing it from sibling tools like get_sector_price or get_stock_chart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool for sector index charts, and it cross-references get_market_index for sector code sourcing. It does not explicitly mention alternatives or when not to use it, which keeps it a step below a perfect 5, but the context is clear enough for an agent to select it appropriately.
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 adds behavioral context by naming the Kiwoom API (ka20001) and enumerating the returned data fields, but it does not disclose output format, pagination, rate limits, or explicitly confirm read-only nature (though '조회' implies it). 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and data fields, followed by parameter guidance. Every clause contributes essential information, and the formatting is clean and scannable. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description enumerates the key return components (index, open/high/low, volume, rising/falling counts, 52-week high/low, time-series trends), which gives a good sense of the response. It also fully covers the single parameter. It lacks explicit differentiation from nearby siblings, but the detailed field list helps. Overall, it is quite complete for a simple query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes sector_code with examples and error behavior. The description adds value by referencing get_market_index as the code source and reinforcing that sector names are acceptable. This goes beyond the schema's details, so a score above baseline is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves current price details of a sector index, listing specific data fields (index, open/high/low, volume, etc.). It distinguishes itself from sibling tools like get_sector_stocks or get_sector_chart by focusing on '현재가 상세' (current price details) and referencing a specific backend API. The verb '조회합니다' unambiguously indicates a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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: to get detailed current price information for a sector index. It also tells users how to obtain the sector_code via get_market_index and that sector names are accepted. However, it does not explicitly exclude alternatives or state when not to use this tool, so it falls short of a perfect score.
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 adds important behavioral detail: dates are settlement-date based (D+2) and default period is 30 days. It does not mention permissions or rate limits, but provides relevant behavior beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences, front-loaded with purpose, then details. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema or annotations, the description covers purpose, parameters, and a behavioral nuance. Could mention output format or limits, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 adds default values and the settlement note but does not significantly enhance parameter meaning beyond what schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves account transaction history (buy/sell) by period, with default 30 days and optional date and stock filtering. It distinguishes itself from sibling tools that focus on prices, holdings, or 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use (querying transactions by period) but does not explicitly state when not to use or mention alternatives. However, sibling tools are dissimilar, so context is clear enough.
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 effectively discloses that the tool retrieves daily estimated data combining two sources, includes specific financial metrics, and has a usage limit (max 90 days). It does not mention side effects, authentication needs, or data freshness, but the read-only nature is implied and consistent with the tool's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two sentences that front-load the main purpose, then provide a usage example and limitation. No unnecessary words or repetition. It earns its place with clean structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one well-documented parameter, no output schema, and no annotations, the description is complete: it explains what data is returned, the period range, and an important exclusion (simulated trading). No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'days', with the schema already providing description and constraints. The description adds minimal extra value by repeating the default and max values and giving a usage example. Baseline 3 is appropriate as the description does not significantly augment the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '조회' (retrieve) and the resource '계좌 자산·수익률 추이' (account asset/return trends), detailing specific components like daily estimated deposit assets and period returns. It distinguishes from siblings by mentioning it's not supported for simulated trading and by specifying the data sources (키움 kt00002 + kt00016).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a typical query example ('내 계좌가 지난 한 달간 어떻게 변했나'), default (30 days) and maximum (90 days) period, and explicitly states it is not supported for simulated trading. However, it does not explicitly compare with sibling tools or give when-not-to-use advice beyond the simulation restriction.
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. It discloses the unique feature of estimated average cost per entity and explains a use case (comparing current price vs average to spot trapped/profitable investors). It also mentions the underlying API code (키움 ka10062), adding context. However, it does not discuss output details or data freshness, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: first states core function, second differentiates and adds interpretive value, third explains a parameter and points to alternatives. Front-loaded with key information, no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, 100% schema coverage, but no output schema. The description explains the purpose, unique average-price feature, and usage direction, but does not clarify the return structure (e.g., columns, order, pagination) or data update timing. Given no output schema, the description should provide more on what the response contains, leaving a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all 5 parameters with descriptions and defaults (100% coverage). The description adds marginal value by explaining the direction parameter in the context of the tool's core concept, but it largely repeats what the schema states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb '조회' and resource: ranking of stocks where institutions and foreigners net-trade in the same direction. It also explicitly distinguishes itself as the only tool providing estimated average prices per entity, setting it apart from sibling tools like get_net_buy_rank and get_investor_trend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance: use this when you need simultaneous same-direction trades and average prices. It explicitly names alternatives for different needs: '주체별로 따로 보려면 get_net_buy_rank(마감 후 12주체)나 get_investor_trend(종목별)를 쓰세요' and highlights the unique value proposition.
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?
No annotations are provided, so the description carries the full burden. It discloses the use of adjusted prices (수정주가 반영) and references Kiwoom API codes, adding behavioral context. It does not contradict any annotations (none provided) and is consistent with a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using one key sentence plus additional detail in the following sentences. It packs important information without redundancy, though the second sentence could be better structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should ideally mention the response format (e.g., OHLCV data). It covers input parameters well but lacks details on what the returned data looks like, leaving the agent slightly uncertain about the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value by explaining the period enum values in Korean, clarifying default values for period, minute_scope, and tick_scope, and showing the relationship between period and the sub-parameters. This goes beyond the schema's enum lists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves candlestick chart data for a stock, specifies the resource (캔들 차트 데이터) and verb (조회), and differentiates from sibling tools like search_stock by advising to use search_stock if the stock code is unknown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to get chart data) and provides a prerequisite (use search_stock if stock code unknown). It does not explicitly state when not to use, but the context makes it clear this is for chart data rather than simple price queries.
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?
The description adds contextual behavior beyond a simple 'retrieve' by explaining how to interpret the metrics (e.g., low PER for value screening) and mentions the Kiwoom API code (ka10026). However, with no annotations provided, it does not explicitly state read-only/safety or describe any side effects, though '조회' implies read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: first states the function, second gives screening use cases, third names alternatives. It is front-loaded with the action and has no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 should explain return structure, but it does not. It also says 'top 100' while the schema allows configurable top from 1-100 with default 20, which could confuse. Usage context is well covered, but output format and pagination are not disclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters exhaustively with descriptions, defaults, and enum values. The description adds no additional parameter-level semantics beyond reinforcing the metric use cases, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the top 100 stocks ranked by PER/PBR/ROE across the entire market, using a specific verb and resource. It also differentiates itself from siblings by noting it is the only valuation-based market scan tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides use cases: low PER/PBR for value screening, high ROE for capital efficiency, high PBR/low ROE for overheat/insolvency. It names alternatives: get_ranking for volume/price change rankings and get_stock_price for single-stock PER/PBR, and states 'this tool is the only one' for market-wide valuation scans.
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?
No annotations provided, but description discloses it takes zero arguments and returns a fixed message, fully describing its simple 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences front-loading purpose, no wasted words. Ideal for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, description completely covers purpose and behavior without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with zero parameters; description confirms no arguments, adding no new info beyond schema. Baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the tool as a health check for the Kiwoom MCP server, using specific verbs ('verify') and resource ('server connection'), distinct from sibling tools that focus on data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to use for server verification, implying use before operations. Could mention no alternatives, but context with siblings makes purpose clear.
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?
No annotations are provided, so the description carries the burden. It clearly identifies the operation as a read-only inquiry ('조회합니다') and provides domain context about the data's significance. However, it does not disclose potential response structure, pagination, or any side effects. The interpretation guidance adds value beyond a basic read-only declaration, but the lack of explicit safety/behavioral details keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using three sentences to cover purpose, interpretation, and alternatives. Every sentence adds value: the first states the core function, the second provides market interpretation, and the third distinguishes it from sibling tools. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with full schema coverage and no output schema, the description sufficiently explains what the tool does and when to use it. It also includes interpretation guidance that aids the agent in reasoning about results. However, it does not mention output format or pagination (though count parameter mentions 'latest first'), but this is not critical for a data-retrieval tool. The absence of annotations is compensated by the description's clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 much beyond the schema for parameters; it mentions credit_type (loan/short) by defining the terms, but the schema already describes each parameter clearly. The interpretation context indirectly helps understand what parameters mean, but no new parameter-specific details are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving new, repayment, and balance trends for credit loans (borrowed money to buy) or short borrowing (borrowed to sell) for a specific stock. It uses a specific verb (조회합니다/retrieves) and distinct resource (신용융자·대주 잔고 추이). It also differentiates from sibling tools by explicitly naming get_stock_lending and get_short_selling as alternatives for other data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: it states that this tool is for individual credit transactions, while get_stock_lending covers institutional/foreign securities lending and get_short_selling covers short selling volume. It also explains interpretation context (credit balance signals forced-selling pressure, short balance signals bearish bets), helping the agent decide when to use it.
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 transparency burden. It discloses the estimated nature of the price (추정평균단가), the distinction between daily and cumulative net buying, and how to interpret the results. However, it doesn't mention any rate limits, data latency, or output format details, so it falls short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact three-sentence structure that front-loads the purpose and uses each sentence for differentiation or interpretation guidance, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description adequately conveys what data is returned (estimated average price and daily/cumulative net buying), and how to use it. It also provides alternatives and the API code, but could specify response structure more explicitly for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 doesn't add meaning beyond the schema for parameters; it repeats the concept of cumulative net buying but doesn't specify parameter syntax or constraints beyond what the schema already lays out.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves estimated average buy prices for institutions/foreigners and daily/period cumulative net buying for a specific stock. It explicitly differentiates from sibling tools by noting get_investor_trend for finer investor breakdown and get_foreign_holding for foreign share holdings, and asserts this tool is the only one providing unit price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use and when-not-to-use guidance: use get_investor_trend for finer investor categories, get_foreign_holding for foreign ownership shares/limit ratio, and this tool when average unit price is needed. Also gives a practical interpretation context (comparing current price vs estimated price to assess profit/loss).
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. It discloses that data is only available during regular market hours and may return empty or zero volumes otherwise, and explains the three view modes. It does not detail return field structure, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences, front-loaded with the core purpose, followed by view modes, market hours, and alternatives. Every sentence provides useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description covers purpose, view semantics, timing constraints, and sibling alternatives. It does not specify the exact return fields, but the agent has enough contextual information 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% parameter description coverage, so the baseline is 3. The description adds only marginal extra semantics, such as the balance view including total buy/sell and net buy, but most parameter meanings are already in the schema. It does not substantially add syntax or formatting details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves stocks with thick or surging order book volumes across the entire market. It explicitly distinguishes from siblings by pointing to get_orderbook for individual stock order books and get_execution_strength for execution strength.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance, including the specific alternatives: '특정 종목 하나의 10단 호가는 get_orderbook, 체결 쪽 힘은 get_execution_strength를 쓰세요.' It also notes that the tool only computes during regular market hours, helping agents decide when it is useful.
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 full burden and explains the behavioral differences between rise/fall and open_rise/open_fall (previous close vs today's open), the market scanning requirement, and the inclusion of an execution strength column for open-based types. It does not disclose auth requirements or rate limits, but for a query tool this is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence contributes: it front-loads the purpose, then details types, constraints, and use cases. It could be slightly more concise (e.g., removing internal API codes ka10027...), but the structure is logical and not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers parameter semantics, constraints, and use cases thoroughly for a 4-parameter tool. However, without an output schema, it only hints at return values (e.g., execution strength column for open types) and does not describe the complete result structure or pagination, leaving some completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters, but the description adds meaning beyond it: it explains the semantic distinction between rise/fall and open_rise/open_fall, why market is restricted for open-based types, and the purpose of min_volume and credit_ratio. This goes well beyond the schema's descriptive text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves daily market rankings ('당일 시장 순위를 조회합니다') and enumerates the ranking types (rise, fall, volume, value, open_rise, open_fall, credit_ratio), making the purpose specific. It distinguishes from siblings by mentioning get_credit_trend for a different use case, though it does not explicitly contrast with other ranking tools like get_valuation_rank.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit conditions for when certain types are valid: open_rise/open_fall require market to be kospi or kosdaq and min_volume to narrow the population, and credit_ratio is for finding forced-sell pressure, with get_credit_trend explicitly named as the alternative for a specific stock's credit balance time series. This gives clear usage guidance, though it does not cover all possible alternatives.
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 full burden. It discloses the tool returns aggregated sector data including investor-type breakdowns and index change. It also notes it fetches all sectors at once. While it doesn't mention auth or rate limits, the read-only nature is clear, and it adds context about the API key (키움 ka10051) and return contents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, then a concise usage guide. Every sentence earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains what is returned (per-sector net buys by investor type, index change). Combined with detailed parameter schema and explicit sibling differentiation, the tool is well-contextualized. Minor gaps like pagination or error handling, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description adds minimal parameter-specific meaning beyond the schema, only implicitly framing the tool's purpose. No extra semantics for top, sort, unit, market, or base_date beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves net purchases by investor type for all sectors at once ('시장 전체 업종의 투자자 주체별 순매수를 한 번에 조회합니다'), with specific verb+resource. It also distinguishes from siblings by naming alternatives like get_investor_trend and get_sector_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context ('오늘 돈이 어느 섹터로 갔나') and directly names alternatives for other use cases: stock-level use get_investor_trend, top stocks use get_investor_rank, sector details use get_sector_price/get_sector_stocks.
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?
No annotations are provided, so the description carries the full burden. It clearly discloses the tool's read-only, query-like nature via '조회합니다' and explains the conceptual meaning of supply/demand zones. However, it does not describe the output format, return fields, or any limitations (e.g., sorting, pagination) beyond what the schema covers, which keeps it from a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. It front-loads the core purpose, then explains the interpretation/use-case, then distinguishes from alternatives. Each sentence earns its place and the overall structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 and no annotations, the description is quite complete: it explains the underlying concept, when to use it, and how it differs from siblings. The only gap is that it doesn't describe the return structure or sample output, which would be helpful since no output schema exists. Nonetheless, the rich schema and clear purpose make the tool mentally invocable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter already having a clear description (defaults, ranges, and meanings). The tool description adds conceptual context about 매물대, which helps understand the parameters, but it does not enrich individual parameter semantics beyond the schema. Thus, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('조회합니다' - retrieves) and the resource ('매물대에 몰린 종목' - stocks concentrated in supply/demand zones). It also differentiates from siblings by naming specific alternatives like get_orderbook and get_market_movers, making the unique 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool ('현재가 위아래 어디에 물량이 뭉쳐 있는지 확인할 때') and explicitly names alternatives for related but distinct tasks (get_orderbook for single-stock orderbook, get_market_movers for volume surges). It even states '가격대별 거래 분포를 보는 것은 이 tool뿐입니다' to emphasize exclusivity.
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 full burden. It discloses the tool's scope (daily cash flow at a glance), lists the specific data fields returned, and highlights a major limitation (unavailable in simulated trading). It doesn't explicitly state the return format or that it's a read-only call, but for a no-parameter query tool, the provided behavioral context is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with dense but purposeful content. It leads with the primary purpose, then enumerates contents, provides sibling comparisons, states exclusivity, and closes with a limitation. Each sentence earns its place, though the listing of comma-separated metrics makes it slightly heavy. Still, it's efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema tool, the description covers the essential context: what data is returned, which sibling tools to use for other needs, and a key environment restriction (paper trading). It could have described the display format or the meaning of D+2, but the information provided is sufficient for an agent to decide when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100%. The description correctly avoids inventing parameters and instead focuses on the query's fixed scope, which is the appropriate semantic content. Per the rubric, 0 params earns a baseline of 4, and the description supports this by explaining what the single-page view includes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'inquires about what happened in the account today at a glance' and enumerates specific content (sell/buy amounts, fees/taxes, deposits/withdrawals, D+2 estimates, credit/loan balances). It explicitly distinguishes this tool from siblings by naming get_trading_journal, get_account_holdings, and get_account_balance for related but different queries, 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance by stating that per-stock realized P&L should use get_trading_journal, current holdings get_account_holdings, and summary balances get_account_balance, then notes 'this is the only tool for viewing daily cash flow.' It also provides a critical exclusion: not available in simulated trading (RC9000).
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?
No annotations provided, so the description carries the burden. It discloses the data source (키움 ka40004), the ~1,150 universe size, performance implication ('좁힐수록 조회도 빨라집니다' via tax_type filter), and a caveat that index_name matches only ~1/4 of tickers. Lacks explicit statement about safety/read-only nature or pagination, but adds meaningful behavioral context given zero annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two dense sentences that pack purpose, scope, examples, and alternatives. Slightly verbose with the Korean phrasing but every clause earns its place. Could be tightened but is efficiently front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Well-completed for a screening tool with 6 params at 100% schema coverage and no output schema. Variables like sort enums and filters are well-explained in schema; description resolves the key decision of when to use it vs siblings. Missing return-format clarification but acceptable given the task type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed param descriptions. The description adds practical context beyond schema: tax_type performance hint, min_volume filtering rationale (거래정지 종목 극단적 괴리율 제거), manager prefix-partial-match semantics, and index_name 1/4 coverage caveat. This enriches the enum and integer params with domain knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb '스크리너' + resource '상장 ETF 전 종목(약 1,150개)' + sort dimensions (괴리율·등락률·거래량·추적오차). Clearly distinguishes from ETFs-only tools (get_etf_info, get_etf_returns) and general stock screeners (get_valuation_rank, get_ranking) by stating it's for when '종목을 아직 고르지 않은 상태에서'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('종목을 아직 고르지 않은 상태에서 찾을 때'), and names concrete alternatives with when NOT to use (get_etf_info, get_etf_returns, get_valuation_rank, get_ranking). Even gives use case examples like 'NAV보다 비싸게 거래되는 ETF', '거래량 많은 ETF'.
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 full responsibility for behavioral disclosure and does so well: it states that surge/plunge and volume_surge are based on '전일 대비' (previous-day comparison), that volume_surge is ordered by surge volume with a 5,000-share minimum, and that volume_renew means today's volume exceeds the max of the prior cycle. This significantly exceeds a minimal 'get movers' statement, though it omits output structure and any rate-limit or auth details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but each clause carries useful information, and the main purpose is front-loaded. It uses semicolon-separated enumerations and parenthetical annotations to pack signal definitions, market options, defaults, and comparative rules into a compact space. Slightly long, but every sentence earns its place given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is remarkably complete: it defines all eight signals, all market values, all relevant time windows, defaults, exceptions, and ordering/threshold behavior. The only omission is return-format details, but the absence of an output schema lowers the burden in that area, and the operational semantics are fully covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already covers 100% of parameters with enums and Korean descriptions, the description adds substantial semantics beyond it: it clarifies that days is only used for new_high/new_low, cycle only for volume_renew, and it explains the comparative logic and thresholds for volume_surge. This is a strong enrichment over the schema, not mere repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource statement ('시장 특이 종목을 조회합니다') and enumerates all eight signal types (new_high, new_low, upper_limit, etc.) with Korean labels. This clearly defines the tool's scope and distinguishes it from broader sibling tools like get_ranking or get_vi_stocks by specifying exact signal semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance for parameter combinations: days only applies to new_high/new_low, cycle only applies to volume_renew, and it explicitly contrasts volume_renew ('longer-term volume breakout') with volume_surge ('previous day only'). However, it does not explicitly compare this tool with sibling market-scanning tools such as get_ranking or get_vi_stocks, so cross-tool guidance is implied rather than direct.
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 and addresses the most important behavioral trait: orderbook quotes are pending orders, not executed trades. It also discloses the 10-level depth, bid/ask composition, and KRX+NXT integration. However, it does not mention data latency, update frequency, or access limitations, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with no filler; the first sentence states the core function, and the remaining sentences provide usage context and sibling distinctions. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and no output schema, the description is complete: it defines the returned data (10-level bid/ask and quantities), explains when to use it, provides alternatives, and covers prerequisite lookup. No additional context is needed for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; stock_code is fully described in the schema with format and example. The description only adds a pointer to search_stock if the code is unknown, which is useful but does not enhance parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('조회합니다'), names the resource ('10단계 매도/매수 호가와 잔량'), and specifies the integration standard (KRX+NXT). It also explicitly contrasts with execution-focused sibling tools, making its 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to use this tool ('지금 어느 가격에 대기 물량이 얼마나 쌓였는지...'), and provides explicit alternatives: get_stock_quotes and get_execution_strength for actual execution flow, and search_stock for unknown codes. This fulfills when/when-not guidance clearly.
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 discloses key behaviors: sorting by stock code (종목코드순) and pagination limitation (first page only, max 100 stocks). It also references the Kiwoom API code (ka20002). It does not elaborate on error handling or auth, but for a read-only quote retrieval tool, the disclosed traits are valuable and beyond what a schema would 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences covering purpose, sorting, pagination, and parameter guidance. It is front-loaded with the main purpose and avoids redundancy or filler. Every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list-query tool with no output schema, the description covers the essential aspects: what it returns (quotes), ordering, pagination, and how to specify the sector. It is sufficiently complete for an agent to select and invoke the tool correctly, even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so the baseline is 3. The description adds value by pointing out that sector_code can be sourced from get_market_index or a sector name, which is not in the schema. This cross-reference helps the agent understand how to construct a valid parameter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: '특정 업종에 속한 종목들의 시세를 조회합니다' (retrieves quotes for stocks belonging to a specific sector). This distinguishes it from sibling tools like get_sector_price (sector index) and get_sector_flow, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by noting that sector_code can be obtained from get_market_index or used directly as a sector name. It implies the tool is for sector constituent stocks, which differentiates it from index-level sector tools. However, it does not explicitly state when not to use this tool 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.
- Behavior4/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 that it queries specific market data fields and the data source. It does not mention authorization, rate limits, or whether the operation is read-only, but the context implies it is a read query. Additional detail on return structure would improve 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose, key data fields, and dependency on another tool. It is front-loaded and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single required parameter and lack of output schema or annotations, the description provides sufficient context for correct usage. It explains what data is returned and how to obtain the input value, making the tool's functionality clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the parameter with a pattern and description. The description adds value by explicitly linking theme_code to the output of get_theme_groups, providing contextual meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves constituent stocks and market prices for a specific theme group, including specific fields like current price, change, change rate, volume, and period return. It also identifies the data source (kiwoom ka90002) and explains how to obtain the theme_code, which distinguishes it from sibling 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that theme_code must come from get_theme_groups, providing clear context for usage. However, it does not explicitly contrast with sibling tools or state when to use this tool versus alternatives like get_stock_price or get_stock_chart.
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?
No annotations provided, so description carries full burden. It discloses that comparison/base is today's closing price (not previous day), and that sort, market, min_volume only affect ranking mode. No contradictions. Lacks details on rate limits or auth but adequate for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph but well-structured: time frame, source, two modes, base price, ranking controls, sibling reference. No redundant sentences. Could split into bullet points for clarity, but currently concise enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description adequately covers return data: quote, 5-step order book, ranking. Explains all 5 parameters and their behavior in each mode. For a read-only tool with 5 params, it is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds significant meaning: explains stock_code toggles mode, clarifies sort options (up_rate, up_amount, etc.), market, min_volume. Provides context of KST time and source codes. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves after-hours single price trading info (16:00-18:00 KST). It distinguishes two modes: with stock_code returns quote and 5-step order book; without returns market-wide ranking. It differentiates from sibling get_orderbook for regular hours.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use (after-hours) and when not to (regular hours use get_orderbook). Explains the two different behaviors based on stock_code parameter presence, guiding the agent on when to provide or omit it.
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. It discloses the default view (flow), what fields are included (closing price, change rate, volume, trading amount, net buys, program, credit ratio), and that session view shows pre/intra/after-hours distribution. It also references underlying API codes. It doesn't discuss rate limits or output format but provides substantial behavioral context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient; every sentence serves a purpose: stating the action, explaining the default view, framing when to use it, describing the alternate view, and listing alternatives. It's front-loaded with the core functionality and has zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, both views, and alternatives thoroughly. It doesn't describe the output structure, but there's no output schema given, so this is a minor gap. It does mention '한 행에 묶어' (bundled in one row) giving some hint. For a complex tool with two distinct modes, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers 100% of parameters with descriptions, but the description enriches meaning by explaining the semantic difference between view=flow and view=session, clarifying the unit default (quantity), and giving practical context for count (default 20, max 60). This adds value beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves daily trading data for a stock in one call (종목의 일자별 거래를 한 번의 호출로 조회합니다). It names the two views (flow and session) and their content. It explicitly differentiates from sibling tools by pointing to get_stock_chart, get_investor_trend, and get_foreign_holding for other needs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: '이 종목을 최근 누가 사고팔았나'를 볼 때 첫 번째로 쓰는 tool입니다 (first tool to use when checking who bought/sold). It also lists three alternative tools with their specific use cases, making the decision boundary clear.
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. It discloses data source (Kiwoom), the meaning of benchmark_index_code (from get_market_index), and the resolution difference for investor view. It does not mention error handling, rate limits, or explicitly state read-only behavior, but the get_ prefix and content make the nature clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph, front-loaded with the main purpose and then breaking down the three views. Every sentence provides useful information, but the density and semicolon-heavy structure could be more readable with bullets or shorter sentences. Still, it is appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description needs to explain return content, and it does: it describes what each view returns (returns vs index, NAV/premium/tracking error, investor net buying) and the benchmark code source. It lacks response format details and edge-case behavior, but covers the essential usage contexts for a 3-view tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial value: it explains the default benchmark index code (201 KOSPI200) and how to find other codes, clarifies the purpose of each view enum, and notes that days applies to daily/investor. This goes well beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves ETF performance from three angles and enumerates each view: period returns with benchmark comparison, daily NAV/premium/tracking error, and investor net buying. It also distinguishes itself from siblings like get_etf_info (snapshot vs trend) and search_stock (code lookup), 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides usage context for each view: period for returns, daily for checking fair value and index tracking, investor for foreign/institutional net flows. It also names alternatives (get_etf_info, search_stock) and clarifies when they are appropriate, effectively telling the agent 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?
No annotations provided, so description carries full burden. It explains the metric, return content (trend data with moving averages for intraday), and data source. However, it does not explicitly state read-only nature or limitations like data freshness, but overall behavior is well-disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise 5-6 sentences with no fluff. Front-loaded purpose, then metric, then view options, then usage context and alternatives. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 params with 100% schema coverage and no output schema, description covers metric, views, and alternatives adequately. Could mention return format briefly, but not essential for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by explaining view options' specific behavior (daily: 60 trading days, intraday: 60 minutes with moving averages) and defaults. Enhances understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves execution strength trend (buy/sell volume ratio) for a stock, explains the metric and interpretation, and distinguishes from sibling tools (get_orderbook, get_investor_trend) with specific alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use (checking if buying pressure is increasing) and when not to use (orderbook or investor trends), including alternative tools. Also explains the two view options (daily vs intraday) with their specific time ranges and features.
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?
No annotations are provided, so the description carries the full burden. It discloses mode-specific content (daily includes institutional/individual net buying, ticks includes execution strength and best bid-ask), the only two listed instruments, default values, and the lack of a stock master. However, it does not describe the return format or mention any error conditions, which keeps it from being a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the purpose, followed by parameter explanations and a usage caveat. Every sentence 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.
Completeness4/5Given 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 covers the core behavior, parameter semantics, and usage boundaries well. It explains what daily and ticks modes return at a high level. The only minor gaps are the lack of explicit return shape and whether rows applies to both modes, but overall it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context by explaining the two instruments (1kg vs 100g mini), detailing what daily and ticks modes include, and explicitly clarifying that base_date is daily-only and that no stock code is needed. This goes beyond the schema's bare enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries KRX gold spot prices with a specific verb and resource. It distinguishes from siblings by explicitly directing gold ETFs/ETNs to get_stock_price and noting that search_stock cannot find gold spot instruments due to the absence of a stock master.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: use for physical gold price (KRW per gram), and for gold ETFs/ETNs use get_stock_price instead. It also warns that stock codes cannot be entered and search_stock is not applicable, preventing common misuse.
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?
No annotations provided, so the description carries the full burden. It explains the tool shows period totals and daily details, and mentions unit options. It is a read-only operation but doesn't describe pagination or limits, which is acceptable for this type of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. It includes the prerequisite (use search_stock if needed) and clearly states what the tool returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with full schema descriptions, and no output schema, the description adequately explains what is returned (period totals and daily details). It is fairly complete for the complexity of this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds meaning to parameters: 'unit: amount(금액, 백만원, 기본)/quantity(수량, 주)' clarifies the enum values, and dates have default explanations. This provides useful context beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries investor buying trends (개인/외국인/기관 순매수) for a stock, specifying it shows period totals and daily details. It also differentiates from sibling tools like search_stock.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use search_stock if the stock code is unknown, providing a clear alternative. The description tells when to use this tool (for investor trend) and indirectly when not to use it (if you don't have the stock code).
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?
No annotations provided, so description carries the burden. It explains default sorting, the effect of stock_code filtering, and that limit is ignored when searching by stock. However, does not mention response format or data freshness, though field list is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences in Korean, front-loading the main purpose, then adding usage details and an alternative. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and sibling tools, the description covers purpose, parameter behavior, and alternative tool. Lists return fields but lacks explicit format details. Sufficient for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions. Description adds context beyond schema by explaining default behavior and that limit is ignored with stock_code, moving beyond baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves Kiwoom theme group list with specific fields (테마명, 종목수, 등락률, etc.), distinguishing from sibling get_theme_stocks which retrieves constituent stocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes default behavior (showing top themes by change rate) and alternative use with stock_code to search for themes containing a specific stock. Directly points to get_theme_stocks for constituent stocks, providing an alternative.
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?
The description declares the tool is read-only (읽기 전용) and mentions the API endpoint ka01300, which adds transparency. It states that group editing is not supported, which is a behavioral limitation. No annotations were provided, so the description carries the burden. It does not discuss error conditions or rate limits, but for a simple parameterless read operation, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose. It includes an alternative tool reference and a limitation. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers the core functionality. It mentions the output fields (group code + group name) and the API code. It could mention more about the output format or potential empty results, but it is sufficiently complete for a simple list retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100%. The description adds meaning by stating what is retrieved (group code + group name). No parameters need explanation, so a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of watchlist groups (group code + group name) stored in the HTS. It uses the verb '조회합니다' (inquiry) and specifies the resource. It distinguishes itself from the sibling tool get_watchlist by noting that get_watchlist is for specific group items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use get_watchlist for specific group items, and states that group editing (add/delete) is not supported by the API, so only inquiry is possible. This provides clear when-to-use and when-not-to-use guidance, with an alternative named.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple read-only expectation by detailing that empty results are a normal state during non-calculation times and not an error. This is valuable contextual information that helps the agent correctly interpret responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses three sentences, each earning its place: the first states the core function, the second explains the concept and optimal usage timing, and the third covers empty-result behavior and alternative tools. It is compact and well-structured without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only ranking tool without an output schema, the description sufficiently covers necessary context. It explains the special timing contexts, empty-result behavior, and points to sibling tools for related but distinct queries. Given the tool's simplicity and the rich schema, no further explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (top, sort, market) have descriptions within the input schema, giving 100% schema description coverage. The tool description itself adds no parameter-specific 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '예상체결가 기준 순위를 조회합니다' (queries ranking based on expected execution price). It explicitly names the underlying source (키움 ka10029) and distinguishes itself from sibling tools by mentioning specific alternatives like get_ranking and get_after_hours.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when the tool is useful (during simultaneous auction phases before open and close), warns when results will be empty (outside Kiwoom's calculated times), and names three alternative tools for different use cases (get_ranking, get_market_movers, get_after_hours). This provides clear when-to-use and 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that figures are based on the last completed trading day and contrasts real-time alternatives, adding valuable temporal context beyond the schema. The performance caveat (15-20 seconds) is already covered in the schema's market parameter, so this is sufficient, though edge cases or error states are not 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense yet concise, with bolded key phrases and a logical flow: verb+resource, usage examples, alternative tools, and data timing. Every sentence provides actionable guidance; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with 5 enums and no output schema, the description provides complete context: what it does, when to use, when not to use, data freshness, and real-time alternatives. It fully complements the schema and sibling tools, leaving no major gaps for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing a baseline of 3. The description adds value by giving example usages that convey parameter combinations (e.g., '사모펀드가 산 코스닥 종목' implies subject=private_fund, market=kosdaq, side=buy), and clarifies that side=net with direction=bottom gives net sell. This enriches the schema's meaning without being redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool scans all market stocks and extracts the top net buy/sell by investor subject, using a specific verb ('뽑습니다') and resource (키움 ka10066). It clearly distinguishes from sibling tools by naming get_investor_trend and get_investor_rank as alternatives, and lists the 12 selectable subjects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance with concrete examples ('연기금이 어제 뭘 담았나', '투신 순매도 상위'). It names exact alternatives for different scenarios: get_investor_trend for a single stock, get_investor_rank for quick foreign/institution view, and get_foreign_intraday for real-time foreign-only. Also specifies data is as of the last completed trading day, clarifying the non-real-time nature.
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?
No annotations are provided, so the description carries the full burden. It discloses the underlying Kiwoom API calls (kt00001, kt00018, kt00004, kt00008) and explains how settlement view breaks down summary estimates. It does not mention rate limits or authentication, but for a read-only account query, the disclosed behavior is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence serves a purpose: it defines the default view, lists its contents, explains the settlement view with a rationale, and names alternative tools. Content is front-loaded with the default view first, and the structure is logical and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description fully covers the possible return content for both views and provides context for when to use sibling tools. It is complete and self-contained, leaving no major gaps for an AI 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial semantic depth beyond the schema by detailing exactly what each view includes (e.g., 예수금, 총평가금액, 손익, D+1/D+2 estimates, fees, taxes). This exceeds the baseline for high schema coverage and significantly enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves account balance data with two views: summary (예수금, 평가금액, 손익 등) and settlement (다음 결제일의 건별 명세). It uses specific verbs and enumerates the exact contents, distinguishing it from sibling tools like get_transactions and get_account_holdings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use each view (summary for overall balance/profit-loss, settlement for upcoming settlement details) and explicitly directs users to get_transactions for past settlement history and get_account_holdings for per-stock balances, providing clear alternatives.
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?
With no annotations, the description fully carries the burden and does so richly: it explains the two modes (stock_code present vs absent), the different return shapes for each view (top 5 brokers, cumulative 50-broker ranking, dropped brokers with times), the 🌐 flag for foreign brokers, and how direction/days parameters affect the result. It also explicitly warns that the data is broker-based, not investor-based, preventing misuse. This is thorough 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph, but every sentence adds value. It front-loads the core purpose and uses formatting (bold, line breaks implied) to highlight key terms. It could be better structured with bullet points for the three views, but given the complexity of the behavior, the length is justified and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two modes, multiple views, optional parameters), the description covers the most important behavior and result types. It doesn't list exact output fields (e.g., whether it returns arrays of objects with specific fields), but the absence of an output schema means the description should compensate; it does so sufficiently for an agent to understand what data to expect, though more detail on the return structure would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema documents all parameters with descriptions (100% coverage), the description adds crucial semantic context beyond them: stock_code presence switches the entire result mode, top means different things depending on view (number of stocks vs number of brokers), direction has different defaults/effects in market-wide vs broker_rank modes, and days only applies to market-wide mode. This adds meaning that the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the tool's purpose: querying securities firm window trading trends ('증권사 창구별 매매 동향을 조회합니다'), and immediately differentiates it from investor-trend tools by emphasizing '창구 기준' (broker-based). It also distinguishes between the two modes (with/without stock_code) and mentions specific view types (top5, broker_rank, dropout), making it clear what the tool does and how it differs from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: use view=top5 for daily top 5, broker_rank for cumulative ranking across all 50 brokers, dropout for brokers that fell off the top. It also explains when to omit stock_code for market-wide foreign broker rankings, and even names alternatives (get_investor_trend, get_foreign_intraday) for foreign net buying by investor type, plus the key distinction that this tool is broker-based. This is exemplary usage 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?
Discloses read-only behavior and data augmentation from master (trading halt, management stocks). Could mention output format or pagination but sufficient given no 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action and source, efficient and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a single-parameter read tool with no output schema; covers prerequisite and return data content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'group' with clear description, examples ('000', 'etf'), and hint to use sibling tool. Schema coverage is 100% and description adds extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves the list of stocks in a watchlist group, specifies source and read-only nature, and distinguishes from sibling tool get_watchlist_groups by indicating its use for finding group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells how to pass group code or name, advises to use get_watchlist_groups if group unknown, and describes the augmented data (name, previous close, market, caution status).
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?
No annotations are provided, so the description carries full burden. It discloses both operational modes, the output fields (close, volume, foreign net change, owned shares, ratio, limit exhaustion), and the important caveat that the data source differs from investor-trade tools and signs may be reversed. This goes well beyond a basic statement of function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise despite covering two modes and ranking subtypes. It front-loads the primary purpose, uses bold for key distinctions, and each sentence adds essential information without fluff. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 optional parameters, two modes, no output schema or annotations), the description covers the main use cases, mode selection, and data source caveats. It doesn't specify the exact ranking output format (e.g., whether it includes stock names/codes), but the description is sufficiently 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions are already detailed, but the description adds critical semantic context: how stock_code and rank interact, which day values apply to which rank mode (limit_surge: 1/5/10/20; period_net: 1/3/5/10/20/60/120; streak: fixed 3 days), and that market/direction apply only in rank mode. This meaningfully exceeds what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool queries foreign ownership/limit trends with two distinct modes: per-stock daily trend and market-wide rankings. The description distinguishes it from sibling tools (get_net_buy_rank, get_investor_trend, get_foreign_intraday) by noting the different data source, so it's specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use stock_code (per-stock trend) vs rank (market-wide rankings) and details each rank type (limit_surge, period_net, streak) with their specific criteria. It also states the tool should be used for foreign ownership/limit data and not as a substitute for investor-trade-based tools, providing explicit exclusions and alternatives.
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?
With no annotations, the description carries the full burden and does so excellently. It discloses that date_rank allows past dates with extra fields, stock_intraday only provides the most recent trading day and ignores base_date, amounts are in million won, and market has no 'all' option. It also notes arbitrage_balance represents unclosed positions, not trades, which is critical 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every clause carries unique information—view definitions, constraints, units, and exceptions. It is front-loaded with the primary purpose and logically organized from view enumeration to parameter applicability. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description indicates key output dimensions for several views (e.g., date_rank includes amount and trade weight; stock_intraday includes quantity) and sets expectations about accuracy and date limitations. However, views like market_daily and market_intraday are only described as '추이' without specifying output fields, leaving a slight gap for a complex multi-view tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. However, the description adds significant inter-parameter constraints: 'direction은 top·date_rank에, unit은 view=top에만, market은 top·date_rank·market_daily·market_intraday에만 적용됩니다 (종목 단위 view와 arbitrage_balance에는 적용되지 않습니다).' This goes beyond per-parameter schema definitions and clarifies combinations, which is highly valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '프로그램 매매 상위 종목과 추이를 조회합니다', clearly stating the tool retrieves program trading top stocks and trends. It then enumerates seven distinct views, differentiating the resource and scope. This is specific and distinguishes it from sibling tools like get_institution_trend or get_foreign_intraday.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: '한 종목의 프로그램 수급이 장중 언제 뒤집혔는지를 보려면 stock_intraday, 날짜별 흐름은 stock_daily입니다.' It also clarifies accuracy trade-offs ('당일 순위는 top이 서버 집계라 더 정확합니다') and parameter applicability exclusions. This is exemplary.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals defaults (trend view, last 30 days, market-wide aggregate if no stock_code), the ignored-parameter behavior with a footnote for balance_rank, and the interpretation of to_date as the base date for balance_rank. This goes beyond basic read-only implication and covers key edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but well-structured: it starts with the core purpose, then explains default behavior, then details the two views, and ends with a cross-reference. Every sentence contributes necessary information with no fluff or repetition, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two views, multiple parameters, no output schema, no annotations), the description covers return content for trend (contracts, repayments, balance, etc.), the nature of balance_rank, parameter restrictions, defaults, and a pointer to a related tool. It provides enough context for an agent to select and invoke the tool correctly without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all 5 parameters with 100% coverage, so the baseline is 3. The description adds meaning by explaining the effect of omitting stock_code (market aggregate), the meaning of to_date for balance_rank, and that stock_code/from_date are ignored for balance_rank. This extra context justifies one point above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides stock lending information with two view modes: trend (daily time series) and balance_rank (cross-sectional ranking). It explicitly mentions the underlying Kiwoom API numbers and differentiates between the two views, and points to a sibling tool (get_short_selling) for related but different data, 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: balance_rank for asking 'which stocks have accumulating lending volume' and trend for a single stock's time flow. It also states that stock_code/from_date are ignored for balance_rank and tells the user to consult get_short_selling for short selling flow, clearly distinguishing when to use this tool vs alternatives.
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?
With no annotations provided, the description fully carries the transparency burden. It discloses that values are provisional in 1,000-share units, may differ from final values after market close, and can even have reversed signs. It also explains why certain investor types are not queryable, adding critical 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidance, caveats, and alternatives. Every segment earns its place, using bold and em-dashes to emphasize key points without redundancy. Despite its length, it remains efficient for the complexity involved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 4 enums, no output schema), the description is complete enough for correct invocation. It covers the real-time scope, investor limitations, provisional value behavior, and explicit tool alternatives, ensuring an agent can decide when to use it and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant meaning beyond the schema: it clarifies that the unit parameter is only valid for the foreign investor, that the market parameter results in server-side sorting, and that investors like individuals and financial investment are not supported. These details are not present in the schema property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts stocks that a specific investor is currently buying during regular market hours ('어떤 주체가 지금 사고 있는 종목') and identifies the resource ('전 종목에서'). It also distinguishes from siblings by explicitly mentioning alternatives (get_net_buy_rank for settled days, get_investor_trend for specific stocks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage guidance: '실시간 수급을 볼 때 쓰세요' (use when viewing real-time supply/demand), and clearly contrasts with post-market and single-stock alternatives. It also states the exchange limitation: individual and financial investment investor types are unavailable during market hours.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/ChunSam/kiwoom-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server