StockLens

Server Quality Checklist

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

Latest release: v0.8.0
Disambiguation3/5
Most tools are clearly separated by market (US vs KR) and data type, but search and search_stock are explicit aliases of the same function, which creates real ambiguity. Additionally, get_us_financials vs get_us_financial_statement have overlapping names and could be confused, though descriptions clarify the difference.
Naming Consistency3/5
The dominant get_ prefix is consistent, but there are several deviations: list_sectors/list_themes, export_to_excel/export_us_to_excel, scan_to_excel/query_excel, screen_by_flow, search/search_stock, and stocklens_status. This mix of get_, list_, export_, scan_, query_, screen_, and bare-verb naming reduces predictability.
Tool Count2/5
With 53 tools, the server is heavily over-scoped. Many bulk variants (get_flow_batch, get_indicators_bulk, get_multi_stocks) and duplicates (search/search_stock) add bulk, making it difficult for an agent to efficiently choose among them. The two-market coverage partially justifies the size, but this is well beyond the typical well-scoped range.
Completeness4/5
The tool set provides broad coverage for both US and Korean markets, including quotes, charts, financials, earnings, analyst opinions, dividends, options, insider trades, ETF details, indices, rankings, themes, indicators, and Excel export. Minor gaps such as Korean full financial statement statements or Korean earnings dates exist, but they are workaroundable via disclosures or financial metrics.
Average 4.2/5 across 53 of 53 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 78 commits in the last 12 weeks
- Last stable release on August 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It only states the high-level purpose and does not mention data frequency, limitations (e.g., only US, quarterly filings), or output structure. This is insufficient for an agent to understand side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes English and Korean translations which are somewhat redundant. It could be more concise by dropping the duplicate translation or combining sentences. The structure (header, examples, Args) is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high number of sibling tools and absence of annotations, the description lacks completeness. It does not explain what the output contains, how to interpret 13F data, or any pagination or filtering details, making it harder for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description for the 'ticker' parameter merely says 'US 티커' (US ticker), adding no additional meaning beyond the parameter name. With 0% schema coverage, more detail (e.g., format, examples) is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns US institutional holders via 13F holdings, with example queries showing its scope. However, it does not explicitly differentiate from siblings like get_us_filings or get_us_insider, though the focus on 'holders' is unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Example queries provide usage context, but there are no explicit when-to-use or when-not-to-use guidelines. Alternatives from the sibling list are not mentioned, leaving the agent to infer.
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 exist. The description only mentions 'snapshot' and does not disclose data freshness, whether it returns last price only, rate limits, or error handling. Behavioral traits beyond basic function are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with purpose, and structured with Args. The mix of English and Korean might be slightly verbose but does not detract from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not explain return values. The description covers usage and parameter constraints adequately for a simple batch price tool, but lacks details on error handling or data fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds that tickers should be a list of tickers with max 20 recommended, which fills a gap since schema coverage is 0%. However, it does not specify format (e.g., symbol only) or that they are US tickers specifically.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for US multi-ticker prices (snapshots) with example queries. The verb and resource are specific. It does not directly differentiate from siblings like get_price or get_us_price, but the name and context imply batch querying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Example queries are provided, implicitly showing use cases. A max recommendation of 20 tickers is given. However, no explicit guidance on when not to use or alternatives is included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It describes the output content but does not mention potential side effects, authentication needs, rate limits, or ordering. The minimal disclosure leaves the agent unaware of important behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear front-loaded purpose, usage hints, and parameter explanations. It is well-structured for an agent to quickly parse, though the usage hint sentence could be considered redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It adequately covers parameter semantics and usage context. However, it could explicitly state the scope (Korean stocks) for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description's Args section compensates well by providing code format (6 digits, example), and count default and max value. This adds crucial meaning beyond the schema's types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves recent securities firm analysis reports for a stock, including target price, opinion, summary, and PDF. The name and usage hints make the purpose unambiguous, but it does not explicitly differentiate from siblings like get_consensus or get_disclosure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use ('리포트', '증권사 분석', '애널리스트 의견', '리서치' 관련 질문). However, it lacks explicit exclusions or alternatives, leaving some ambiguity among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden for behavioral traits. It only states it returns headlines but does not disclose error behavior, rate limits, pagination, or output structure. The existence of an output schema partially mitigates this, but more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear title, example queries, and parameter list. Every sentence earns its place with no redundancy. Ideal for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with an output schema, the description covers core purpose and parameters. However, it lacks details on expected input format (e.g., ticker case) and error handling, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaningful semantics: 'ticker: US 티커' clarifies domain, and 'limit: 헤드라인 개수 (기본 10)' defines the parameter's role and default. This provides value beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides US stock news headlines and gives example queries. It is specific about the resource (US stock news) and the verb (get). However, it does not explicitly differentiate from sibling tools, though no other news tool exists among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example queries to indicate usage, but lacks explicit guidance on when to use versus alternatives or when not to use. Since there are no alternative news tools, the examples suffice to imply usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the tool returns a list and EDGAR URL, with no mention of side effects, authentication, rate limits, or any behavioral traits beyond the obvious read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with a brief intro, example queries, and an Args section. Every sentence adds value, no filler, and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description doesn't need to explain return values. It provides enough context for an AI to understand the tool's purpose and parameters, though it could mention prerequisites (e.g., valid US ticker) or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning: ticker is 'US 티커' and limit is '표시할 공시 건수 (기본 15)', clearly explaining their purpose and default. This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for US SEC filings (10-K, 10-Q, 8-K) and provides EDGAR URLs, with example queries. It distinguishes from many siblings by focusing on filings, but does not explicitly differentiate from get_disclosure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Example queries like 'AAPL 10-K' and 'NVDA latest filings' indicate when to use the tool, but there is no explicit guidance on when not to use it or mention of alternative tools like get_disclosure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It states it saves a file and returns a file path, but fails to disclose side effects such as overwriting behavior, permissions needed, or file size limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a title, use cases, Args section, and Returns. It is concise but informative, though slightly verbose with the use case examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters, return value, and use cases. It is reasonably complete given the tool has an output schema and simple parameters, though it lacks error handling details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates with an Args section explaining each parameter (data_type options, code format, days default, filename optional). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports single stock data to Excel and provides use cases (transfer to AI or analyze in Excel). However, it does not explicitly differentiate from sibling tools like export_us_to_excel, which could cause confusion for the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context for when to use (e.g., for analysis in Excel or sending to other AI) but does not specify when not to use it or suggest alternatives among siblings like export_us_to_excel or scan_to_excel.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The tool is a simple read operation, and the description implies no side effects. However, with no annotations provided, the description could more explicitly state that it is read-only and disclose any limits on count or behavior for unknown sectors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. It includes both a summary and parameter documentation. The bilingual nature slightly reduces conciseness but is still clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description adequately covers the input parameters and basic behavior. It could mention the output format or error handling, but for a simple list retrieval tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section adds meaningful descriptions for both parameters: sector_name is explained with examples, and count has a default value and purpose. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: fetching a list of stocks for a specific sector. It provides example queries and mentions partial matching, distinguishing it from sibling tools like list_sectors or get_theme_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives examples of when to use the tool (sector-related questions) and mentions partial matching support. However, it does not explicitly contrast with similar tools like get_theme_stocks or provide guidance on 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks behavioral details such as read-only nature, data freshness, or authorization requirements. Merely states purpose without depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Includes bilingual content and structured Args section, but the Korean examples add length without universal clarity. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return values are covered. Inputs are well-documented. However, does not clarify how this differs from get_sector_stocks, a nearly identical sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description enumerates valid sector_key values and documents default for top_n, adding essential meaning beyond the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it provides US sector overview with top companies and market share. Examples in Korean clarify use cases. Distinguishes from siblings like get_sector_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes example queries for when to use, but does not explicitly state when to avoid or differentiate from alternatives like get_sector_stocks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It only lists the information fields but does not mention that the tool is read-only, has no side effects, or any authentication or rate limit requirements. It fails to provide sufficient 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one line of explanation and one line of parameter details. It front-loads the key information, though the mixed Korean and English might be slightly confusing for non-Korean speakers. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It covers the core data points (index, expense, returns, holdings) and provides examples for the parameter. For a simple info tool, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the parameter 'code', but the description compensates by explaining that it is an ETF ticker code and provides two concrete examples ('069500' and '360750'), adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides ETF detailed info including underlying index, expense ratio, returns, and top 10 holdings. It distinguishes from sibling 'get_us_etf_info' by providing Korean market examples (e.g., '069500' KODEX 200).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for Korean ETF details via examples, but does not explicitly state when to use this tool versus alternatives like get_etf_list or get_us_etf_info. No when-not or alternative recommendations are given.
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 provided, so description carries full burden. It describes output content (holdings, sectors) but does not disclose behavioral traits such as read-only nature, rate limits, or authentication requirements. Minimal 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief and front-loaded with purpose, followed by examples. Mixed language (Korean/English) is acceptable for context. Every sentence adds value, though could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema but details not shown. Description covers typical ETF info queries but lacks behavioral or authentication context. Adequate for a simple single-parameter tool, but missing transparency elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning by defining ticker with examples ('SPY', 'QQQ', 'VOO', 'SCHD'). This provides practical context beyond the schema's type and required flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides US ETF details (top holdings, sector weight, asset allocation) with example queries like 'SPY 구성종목' and 'QQQ holdings'. It distinguishes from sibling tools such as get_etf_info (likely for Korean ETFs) through the 'US' prefix and specific examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context via example questions ('SPY 구성종목', 'QQQ holdings') and specifies ticker examples. However, lacks explicit when-not-to-use or alternative tool references, though sibling list context implies US ETF specificity.
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 bears full responsibility for disclosing behavior. It only indicates a fetch operation ('가져옵니다'), implying read-only access, but lacks details on authentication, rate limits, potential side effects, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with the purpose front-loaded, followed by example queries and parameter descriptions. Every sentence contributes value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. However, the description omits details like time frame (e.g., daily change) and ordering behavior. It is adequate for basic use but lacks completeness for more nuanced queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by explaining each parameter: direction (up/down), market (KOSPI/KOSDAQ/ALL), and count (default 50, max 500). This adds meaningful semantics beyond the schema's type and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches stocks sorted by change rate (top/bottom) and provides example queries like '상한가 종목', '급등주', etc. This distinguishes it from sibling tools such as get_market_cap_ranking and get_volume_ranking, which focus on different criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete examples of when to use the tool (e.g., for questions about soaring stocks, top gainers). While it does not explicitly state when not to use it or mention alternatives, the context derived from sibling names and the tool's purpose implies appropriate usage.
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 should cover behavioral traits. It does not mention any side effects, rate limits, authentication needs, or whether the data is real-time or delayed. The tool appears read-only but this is not explicitly stated. The description lacks transparency about behavior beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a title, explanatory paragraph, and an 'Args' section listing parameters. It is moderately concise; every sentence adds value. Minor redundancy could be trimmed (e.g., the example about Samsung/Hynix is helpful but slightly verbose), but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description does not need to explain return values. It covers parameter semantics well but lacks context on error handling, data freshness, or edge cases (e.g., what happens when count exceeds max). For a simple ranking tool this is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameter details are absent in the schema. The description compensates fully: it explains market choices (KOSPI/KOSDAQ/ALL), count (default 50, max 500), and sort_by (volume as shares, trade_value as won). This adds significant meaning beyond the schema's type and default information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves top stocks ranked by volume or trade value. It distinguishes between the two ranking criteria and uses specific verbs like '가져옵니다' (retrieves). The sibling tools include other rankings (get_change_ranking, get_market_cap_ranking), so this tool is uniquely for volume/trade value ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use sort_by='volume' vs 'trade_value', including a practical example for high-priced stocks. It explains that 'volume' defaults to number of shares and 'trade_value' to Korean won. However, it does not discuss when not to use this tool or compare it to other ranking tools beyond naming siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states it retrieves a list of recent disclosures. It discloses no behavioral traits such as read-only nature, error handling, pagination, or rate limits, which are important for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. The purpose is front-loaded in the first line, followed by usage context and parameter details. Every sentence is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and an output schema available, the description adequately covers the context. It explains the data source (DART) and type of information (recent disclosures). Missing details like date range or limitation to recent, but overall sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the input schema by specifying that the 'code' parameter requires a 6-digit stock code (e.g., '005930'), providing concrete formatting guidance. With 0% schema coverage, this compensates well for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a list of recent disclosures for a stock from DART. It specifies the stock code parameter and provides example queries (disclosure, IR, etc.), making its purpose distinct from siblings like get_price or get_us_filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions when to use the tool (questions about 'disclosure', 'IR', etc.) but does not exclude alternatives or provide when-not-to-use scenarios. Given sibling tools cover other domains, this is adequate.
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 bears the full burden. It does not disclose behavioral traits such as data refresh frequency, source (e.g., SEC filings, provider), whether results are cached, or any limitations. The only added context is that quarterly earnings (10-Q) are key events, but that's not a behavioral trait of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences plus an args line. The first sentence states the tool's purpose, the second gives example queries, and the third provides context about US earnings. Every sentence adds value with no redundancy. The structure is front-loaded with the main function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown here but indicated), the description does not need to explain return values. It covers the main purpose, parameter usage, and contextual importance of earnings. For a simple one-parameter tool, it is adequately complete, though it could add a note about the result type (e.g., dates, numbers).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'ticker' parameter with no description. The description adds 'ticker: US 티커 (예: 'NVDA')', which clarifies that this is a US ticker symbol. With 0% schema coverage, the description compensates well by specifying the ticker format and giving an example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns US earnings calendar including next earnings date and EPS surprise history. It provides example queries (e.g., 'AAPL 실적 언제') and distinguishes itself by focusing on earnings-specific data, which is not covered by siblings like get_us_price, get_us_financials, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage examples and context (e.g., when to ask about earnings dates). While it does not explicitly list alternatives or when not to use, the examples and mention of 'US earnings date / EPS surprise' make the usage clear. Sibling tools are not contrasted, but the description is sufficient for the intended queries.
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 bears full responsibility for behavioral disclosure. It does not mention rate limits, authorization needs, error handling, or what happens if an invalid ticker is given. Only the metrics returned are listed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary, example queries, a bullet list of returned metrics, and a parameter description. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema, the description lists the returned metrics, which is helpful. It is mostly complete but could mention if ticker must be a valid stock or any constraints on the input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning by specifying the parameter is a US ticker with an example ('AAPL'). This goes beyond the schema's minimal definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns US stock financials and valuation ratios (PER, PBR, etc.), with example queries like 'AAPL PER'. This distinguishes it from sibling tools focused on price, charts, or filings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides example queries that indicate when to use (e.g., valuation questions), but does not explicitly state when not to use or suggest alternatives. The context is clear enough for an AI agent to infer usage.
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 bears full responsibility. It prominently warns that data is 2-4 weeks stale due to FINRA bi-monthly reporting, and advises checking the 'date_short_interest' field. This is a critical behavioral trait for agents. No other behavioral issues are mentioned, but the warning covers the key risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with the core purpose, then usage examples, followed by a critical warning, and ending with parameter definition. It is efficient with no redundant information, though the title is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (handling return values), the description covers purpose, usage, staleness, and parameter adequately. It could mention whether data is point-in-time or historical, but the output schema likely contains that. Overall, it is fairly complete for a simple single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter description only adds 'US 티커' (US ticker) for the ticker parameter, which is minimal and does not compensate for the 0% schema description coverage. It lacks examples (e.g., 'AAPL') or format details, relying on the tool name to imply US focus. More would be needed for the agent to use it correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves US short interest data, specifying metrics like % of float and days to cover. Example queries (AAPL short interest, GME 공매도, short squeeze) further clarify the tool's specific function, distinguishing it from sibling tools that lack short interest focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage examples and an important staleness warning, guiding when to use the tool. While it does not explicitly state when not to use it, the context and sibling tools imply no direct alternative for short interest, making the guidance adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'snapshot' implying current data, lists indices included, but does not detail update frequency, permissions, or return structure. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences covering key info in English and Korean. Slightly redundant but still efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no annotations, the description is reasonably complete for a simple snapshot tool. It could mention real-time vs. delayed, but output schema likely covers return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters; the description implies the tool returns a fixed set of indices without requiring arguments. This meets the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a snapshot of US market indices (S&P 500, Dow, Nasdaq, VIX) and gives example queries, distinguishing it from sibling tools like get_index or get_us_price by focusing on index aggregates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit example queries ('시장 지수', 'S&P 지금', etc.) indicating when to use the tool, but does not mention when not to use it or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear the burden. Only describes search behavior; does not explicitly state it is read-only or disclose any side effects. Minimal extra behavioral context beyond basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with front-loaded purpose, examples, a warning, and arg description. No fluff, but the bilingual text slightly increases length. Still efficient for its content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers parameter semantics and usage guidance well. Output schema externally provided, so return value explanation unnecessary. Lacks mention of error handling or rate limits, but for a simple search with one param, adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description provides useful clarification: 'query: 검색어 (회사명·티커, 한/영 무관)' – explains it accepts company names, tickers, in Korean or English, adding value beyond schema's generic 'Query'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the tool as a US stock search for company names/tickers, with examples. Differentiates from sibling search tools by focusing on US stocks and providing specific guidance for Korean 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to call this tool first when user gives company names like '애플' and instructs to confirm with user if multiple results. Lacks explicit when-not or alternative tool references, but the guidance is clear.
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 bears full responsibility for behavioral transparency. It mentions max 500 codes and the caching pattern, but lacks details on file overwriting behavior, error handling, performance implications, or any prerequisite permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 sentences) and well-structured: a headline summary, a workflow note, and a bulleted list of parameters. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple data types, Excel output, caching pattern and an output schema present), the description covers the essential aspects: purpose, workflow, parameters. It could briefly mention the return value (file path) or limitations, but overall it is sufficiently complete for an AI agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides clear, concise explanations for all four parameters in the 'Args' section, directly addressing the 0% schema description coverage. Each parameter's meaning, default value, and constraints are covered (e.g., codes max 500, days default 260 weeks, include_financial toggle, filename auto-generation).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: scanning multiple stocks to collect basic info, chart statistics, and financial indicators and saving to Excel. It also introduces the local cache pattern for repeated filtering via query_excel, distinguishing it from sibling tools that retrieve data without saving to files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly outlines the workflow: scan first, then use query_excel for filtering. This gives clear usage guidance. However, it does not directly state when not to use this tool or mention alternatives among siblings, such as get_multi_stocks for in-memory data.
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 description must cover behavioral traits. It mentions no row limit and no token consumption, but lacks details on rate limits, file size limits, or potential side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose, use case, and args clearly separated. Includes some Korean text which may be extraneous for English agents, but overall efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema (though not shown), description covers main use case and parameters thoroughly. Lacks mention of prerequisites or error handling, but complete enough for a straightforward export tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates by listing valid values for period and interval, giving ticker examples, and explaining filename auto-generation. Adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it exports US stock long-term data to Excel with no token consumption. It distinguishes itself from get_us_chart by noting the 500-row limit, making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises use for long-term data, backtesting, CSV, or upload to other AI, and contrasts with get_us_chart's row limit. However, it does not mention when not to use or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does mention the data limitation, but it does not disclose whether the tool is read-only, has any side effects, error handling, or permission requirements, leaving behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with line breaks but is somewhat verbose, including a warning and usage examples. It could be slightly more concise while retaining key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, limitations, and alternative tool, which is sufficient for a simple read operation. However, it does not explain the output format or any error conditions, though an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described clearly: code (6-digit stock code) and days (number of days, default 20). The description covers the schema parameters fully, despite the schema itself lacking descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool fetches investor supply-demand data (institutional and foreign net trading stock counts) for a single stock, distinguishing it from the batch version. It also specifies the source limitation (no individual net trading).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use get_flow_batch when there are 2 or more stocks, and provides example user queries ('외국인 수급', '기관 순매수') to indicate when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns 'current values' but does not specify data freshness, update frequency, or any side effects. For a simple read-only tool, this is adequate 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the core function and then adding example queries. Every word is purposeful, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and an output schema exists, the description covers the essential purpose and usage context. It could mention that indices are Korean-market specific, but that is implied by 'KOSPI' and 'KOSDAQ'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no need for parameter explanations. The description does not contradict the schema and provides sufficient context by naming the specific indices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves current values of KOSPI and KOSDAQ market indices, and provides example queries that illustrate its purpose. It effectively distinguishes itself from sibling tools that deal with stocks, charts, or specific indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit example queries (e.g., '코스피', '코스닥', '시장 지수') indicating when to use the tool. However, it does not mention when not to use it or provide alternatives for related but distinct 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?
With no annotations, the description covers partial matching for the theme name and parameter guidance (include_reason affecting token usage). It is a read-only operation with no destructive hints needed. The description adequately discloses 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose, followed by parameter explanations. It is well-structured in Korean with clear parameter names. Minor improvement could be using bullet points, but it is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 parameters, no nested objects) and presence of an output schema, the description covers purpose, parameter semantics, and a key behavioral trait (partial matching). It is complete enough for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides detailed explanations: theme_name with examples, count with default value, and include_reason with a strategic recommendation to omit for token savings. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves stocks belonging to a specific theme, with concrete example queries. It also mentions partial matching for the theme name. This distinguishes it from siblings like list_themes (which lists themes) and get_sector_stocks (by sector).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example use cases and implies usage for theme-based stock queries, but it does not explicitly state when not to use it or compare to alternatives like list_themes for discovering available themes.
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 explains that the tool returns mean/high/low price targets, buy/hold/sell distribution, and recent upgrades/downgrades. This gives the agent clear behavioral expectations beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long with mixed languages and includes an 'Args' section. It is front-loaded with the purpose, but could be more concise by removing redundancy (e.g., example queries could be shorter).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema (not shown but exists), the description covers the key return fields. It is sufficiently complete for a simple retrieval tool, though it could mention what happens if the ticker is invalid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'ticker' has 0% schema description coverage. The description adds meaning by providing an example ('NVDA') and specifying it is a US ticker. While not exhaustive, this compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns US analyst ratings, price targets, and upgrades/downgrades. It provides example queries in both Korean and English, making the purpose unmistakable. It also distinguishes itself from sibling tools like get_consensus by specifying it covers price targets and rating distributions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes example queries that indicate when to use the tool (e.g., for analyst rating questions). It does not explicitly mention when not to use it or compare to alternatives, but the examples provide good contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes a read-only screener with safe behavior, but does not mention rate limits, pagination, or result format details (though output schema exists). It 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: overview, examples, preset list, then parameters. Every sentence is useful, though it mixes Korean and English. A bit longer than necessary, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two optional parameters, a full preset list, and an output schema, the description covers all needed context. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the schema: it lists all preset options with friendly names, specifies default values, and explains the purpose of each parameter. Schema coverage is 0%, so the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it is a US stock screener for predefined presets, with examples like 'today's top gainers' and a full list of presets. This clearly distinguishes it from sibling tools that provide individual stock data or general search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete example questions and lists all available presets, giving strong guidance on when to use this tool. However, it does not explicitly mention when not to use it or suggest alternative tools for custom screening.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It discloses that the watchlist is shared across DartLens and TelegramLens, which is a meaningful behavioral trait, and implies mutation via add/remove/clear. However, it does not explicitly describe side effects (e.g., persistence, immediate visibility, or whether operations are destructive), and lacks details on auth or rate limits. The description adds some value but is not exhaustive for a mutation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, usage context, and an Args section. It includes Korean examples that add value but also length. It is not overly verbose and front-loads the purpose and usage guidance, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (though not shown), the description need not explain return values. It covers the tool's actions, shared behavior, and integration with other tools, which is sufficient for a watchlist manager. It lacks some explicit details about what happens on add when the item already exists, but overall it is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining both parameters: action with allowed values (list/add/remove/clear) and query with example types (stock name or 6-digit code) and its use for add/remove. This is exactly what the agent needs to set parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages a watchlist ('관심종목') with actions list/add/remove/clear, and specifies it is shared across multiple lenses. It is specific and distinguishes itself from data retrieval tools by focusing on watchlist management, and even references related batch tools for consumption of its output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage context: requests like '내 종목' or '관심종목' and mentions that the list is shared with other lenses. It also instructs to pass the returned codes directly to batch tools (get_multi_stocks, get_flow_batch, get_indicators_bulk) and warns against querying stocks individually. However, it does not explicitly state when not to use the tool or mention alternative tools for similar actions, though the context is solid.
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. The description discloses that prepost is only valid for intraday intervals and limit constraints. It implies read-only data retrieval but does not detail other behavioral aspects like rate limits or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: one-line summary, example queries, sibling note, then argument list with clear formatting. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's straightforward purpose (OHLCV data), the description covers parameters and usage context well. Some edge cases (valid period-interval combinations) are not addressed, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates fully. It documents all 5 parameters with meanings, allowed values (for period and interval), defaults, and constraints (prepost intraday only, limit max 5000). This adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides US stock chart OHLCV historical data, with example queries like 'AAPL 차트'. It distinguishes from sibling tool 'get_chart' for Korean market.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit examples of when to use (US stock queries) and distinguishes from get_chart for Korea. It also recommends export_us_to_excel for large data. However, it does not explicitly exclude other alternatives like get_us_price for non-chart data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states it returns US stock info but does not disclose behavior like data freshness, authentication needs, or error handling. Given the simplicity, it is adequate but could mention that it only works for US tickers and returns a profile object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the tool's purpose, and includes clear args. Every sentence provides value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool's purpose is straightforward, the description covers the essential information: what it returns (profile info) and what input is required (ticker). No gaps for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'ticker' is described as 'US 티커 (예: AAPL, NVDA)' which clarifies the input format and examples. With 0% schema coverage, the description adds necessary meaning beyond the schema field name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns US company profile information including sector, industry, market cap, and business summary. Examples like 'Apple 어떤 회사' illustrate usage. It distinguishes from sibling tools that focus on market data, news, or financial statements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example queries and indicates this tool is for obtaining company profile information. While it does not explicitly exclude other tools, the context and siblings make it clear when to use this tool. A brief note on not using for price or news data would improve clarity.
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 the tool returns Form 4 filings and a recent 6-month net purchase summary. While not exhaustive, this conveys the key behavioral trait for a simple single-parameter 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. It uses a mix of languages which may slightly reduce clarity, but overall it is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers the essential information: what data is returned (Form 4, net summary) and the parameter meaning. It is adequate for a focused tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a 'ticker' parameter with no description. The tool description adds 'US 티커' (US ticker), providing semantics beyond the schema. For 0% schema coverage, this clarifies the parameter meaning sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves US insider trading data, specifically Form 4 and a 6-month net purchase summary. Example queries like 'AAPL insider trading' illustrate usage. This distinguishes it from sibling tools, which focus on prices, financials, or 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example queries that imply appropriate usage scenarios. It does not explicitly state when not to use or offer alternatives, but given no sibling tool covers insider data, the context is 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?
The description discloses that the tool uses server-side parallel execution (asyncio.gather) and that the default days parameter is shorter than the single tool to save tokens. No annotations are provided, so the description carries the full burden; it covers key behavioral aspects without raising concerns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, with a clear first paragraph for purpose and performance, and a second paragraph for parameters. The Korean title '수급벌크 —' could be trimmed, but overall the 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (reducing the need to explain return values), the description covers purpose, performance, parameters, and usage examples. It could mention error handling for exceeding the 30-code limit, but for a simple batch query tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining that `codes` is a list of stock codes with a maximum of 30, and `days` defaults to 5 with a maximum of 20, also noting the token-saving rationale for the shorter default. This adds significant meaning beyond the schema's titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool batch queries investor flow (institutional/foreign net trading) for multiple stocks in parallel. It explicitly differentiates from the sibling `get_flow` by highlighting performance benefits (using asyncio.gather internally).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete example questions where the tool should be used, such as comparing flow across stocks. It mentions that it is faster than calling `get_flow` N times, but does not explicitly state when to prefer the individual tool over this batch variant. However, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains it performs parallel judgment, returns only aggregate values (not time series), and has a 100-stock limit. It warns about visualization needs. It does not mention rate limits or auth, but the behavior is clearly non-destructive and read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a bullet list. It is front-loaded with the most critical information (purpose, warning, alternative). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need no explanation. The description covers purpose, parameter details, and references sibling tools for more detail. It is sufficient for an agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It describes each parameter: codes (stock list, max 100), days (default 260), include (default list, references get_indicators), timeframe (enumerated values), params (override, common to all). This adds meaning beyond schema titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it evaluates indicators for multiple stocks (up to 100) in parallel, and distinguishes itself from 'get_indicators' (single stock, repeated calls) and 'get_chart' (visualization). The term '기술지표벌크' and '스크리닝 핵심' reinforce its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool instead of calling 'get_indicators' multiple times, and notes that for time series or candles, 'get_chart' should be used. It implicitly guides toward screening scenarios. However, it does not explicitly list all cases when to avoid 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 are provided, so the description carries the full burden. It discloses the data source (log file paths), the metrics computed (call count, latency percentiles, token usage, cache hit rate, error count), and the parameter's effect (days with default/max). It does not mention failure modes, but for a read-only metrics tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line summary, purpose, a bullet list of metrics, log file paths, and Args. It is slightly detailed but every part adds value, especially the log locations which are crucial for understanding where the data comes from.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no annotations, and an output schema present, the description provides sufficient context: what metrics are returned, what the 'days' parameter does, and where the data is read from. A minor ambiguity remains about whether results are a single aggregate or a per-day breakdown, but the output schema would clarify that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only gives 'days' with type integer and default 1, with 0% schema description coverage. The description fully compensates by explaining the meaning ('조회할 일수' — number of days to query), the default behavior ('기본 1, 오늘만' — today only), and the maximum ('최대 30').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '사용량통계 — 최근 N일간 MCP 도구 사용량을 집계해서 보여줍니다' (aggregate and show MCP tool usage for the last N days). It distinguishes itself from all siblings, none of which are about tool usage metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description labels the tool as '디버깅/최적화용' (for debugging/optimization), giving clear context on when it is appropriate to use. It does not explicitly mention alternatives or exclusions, but no sibling tool serves the same purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It identifies the tool as returning dividend history and yield, implying a read-only operation. It does not explicitly state it is non-destructive or require authentication, but for a simple 'get' tool, the description provides adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lean and well-structured: a header, example queries, and a concise args list. Every sentence adds value, with no redundant or excessive text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown but indicated), the description does not need to detail return values. It covers purpose, usage, and parameters fully, and the sibling tools context shows it fills a specific niche.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates by explaining both parameters: ticker (US ticker with examples) and limit (default value and purpose). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns US dividend history with ex-date and yield, and provides specific example queries that differentiate it from sibling tools like get_us_price, get_us_earnings, etc. The verb is implied (get/retrieve) and the resource (dividend history) is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete example queries (e.g., 'AAPL 배당', 'KO dividend yield') that indicate when to use this tool. However, it does not explicitly mention when not to use it or provide alternatives, though the context of sibling tools makes the use case 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, the description carries full burden. It discloses that Greeks (delta/gamma/theta) are not included, which is a key behavioral trait. It also explains default parameter behavior. However, it does not mention rate limits, authentication, or output structure (though an output schema exists). The transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and examples, followed by structured parameter details. It is not overly verbose, though the multilingual examples could be considered slightly extraneous. Overall, it is efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, output schema present), the description covers purpose, defaults, exclusions, and parameters completely. It does not explain the output schema (handled elsewhere) or mention data freshness, but it is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The 'Args' section explains each parameter in detail: ticker format ('AAPL'), expiration date format and default, and strikes_around_spot meaning and default value. This fully clarifies parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves US options chains (calls/puts, IV, OI) and provides example queries like 'AAPL options' and 'NVDA implied volatility'. It also specifies what is not included (Greeks). This uniquely identifies the tool among siblings, as no other option-specific tool exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives natural language example queries that effectively illustrate when to use the tool (e.g., 'AAPL options', 'Tesla 콜옵션'). It explains default behavior (nearest expiration, strikes near spot) but does not explicitly state when not to use or mention alternatives. However, given no sibling options tool, this is sufficient.
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 that the tool returns about 79 sectors sorted by daily change rate, which is key behavioral information. It does not explicitly state that it is read-only or has no side effects, but that is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each providing value (title, usage, behavior). However, the structure could be cleaner, e.g., separating a formal title from the description text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and an output schema (assumed present), the description provides sufficient context: what it returns, approximate count, sorting, and example queries. An agent can confidently decide when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. According to guidelines, the baseline for 0 parameters is 4. The description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool fetches a list of sectors (업종) from Naver Securities, sorted by daily change rate. It also provides example queries ('업종별 현황', '섹터 리스트', '업종 등락률') that distinguish it from sibling tools like get_sector_stocks or list_themes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases in the form of query examples, but does not explicitly state when not to use this tool or mention alternatives. However, the examples strongly imply when it is appropriate.
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 the description discloses sorting by day-over-day change rate and pagination limit. With an output schema present, this is sufficient for a read-only list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: purpose, usage examples, pagination details, and parameter definition. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity list tool with an output schema, the description covers pagination, sorting, and typical use cases. It is nearly complete, though could mention data freshness or caching.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in schema), so the description's explanation of 'page' (range 1-7, default 1) adds critical semantic meaning. Could mention behavior for out-of-range values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the theme list from Naver Securities, with example queries differentiating it from sibling tools like list_sectors. The verb 'list' and resource 'themes' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives example questions for when to use the tool and mentions pagination details (7 pages, 40 items each). It implies usage context but does not explicitly exclude other 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?
With no annotations, the description fully carries behavioral burden. It discloses local filtering (no HTTP), implying read-only behavior. It does not mention auth or side effects, but these are not critical for a query tool. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose sentence, followed by filter format block and Args list. It is reasonably concise, though the Args list could be slightly shorter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (true), the description does not need to cover return values. It adequately covers input parameters, filter syntax, and sorting/limiting. Missing details like pagination are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but the description provides detailed parameter semantics: file_path source, filter format with examples, sort_by column names, descending default, limit default. This fully compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries a stored Excel snapshot from scan_to_excel, with local filtering. The verb 'filter' and resource 'Excel snapshot' are specific, and it implicitly distinguishes from 'scan_to_excel' (scanning) and other get_* tools (online data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description links the tool to scan_to_excel output and mentions it's local and fast (no HTTP), giving clear context. However, it does not explicitly state when not to use it or list direct alternatives, leaving some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that it returns status for KRX and NYSE/NASDAQ including weekend, holidays, and market session states. Adequate but could mention data latency or real-time nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences in Korean are concise and front-load the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description is complete: it covers scope (Korean/US markets) and types of information returned. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% vacuously. Baseline 4 is appropriate as description adds no further parameter info, but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the current status of Korean and US markets, including whether closed and recent/next trading days. It is distinct from sibling tools which focus on specific data like prices, charts, or financials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it 'before stock analysis to check reference time', providing a clear usage context. It doesn't mention when not to use, but the specific purpose makes exclusion obvious.
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, description handles transparency well by noting parallel bulk query, aggregate-only return. Could add details on error handling or rate limits but sufficient for a read 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bold key points, bullet args, and caution emoji. Slightly verbose in places but mostly efficient for a tool with 2 params.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists (not shown), description needn't detail return format. It lists returned fields and provides usage context. Adequate for a bulk stats tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description explains both params: codes (list of stock codes, max 100) and days (lookback period, default 260 days). Adds practical meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns aggregate statistics (current/high/low, drawdown, period return) for multiple stocks in parallel. Distinguishes from sibling 'get_chart' which returns time series candles/OHLCV.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use (bulk aggregate queries instead of multiple get_chart calls) and for screening (e.g., drawdown filter). Also warns 'not time series' to avoid 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?
Discloses data source (Yahoo Finance, max 15-min delay) and lists all returned fields. No annotations provided, so description carries burden; adequately transparent for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary, examples, fields, and args. Slightly verbose due to bilingual text, but front-loaded and each part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema so return details are covered; description adds additional context not in schema. Complete for a single-parameter stock price tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter 'ticker' lacks schema description (0% coverage), but the description adds full context: 'US 티커' with examples 'AAPL', 'TSLA', etc., fully compensating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves US stock price snapshots for NYSE/NASDAQ, distinguishes from siblings like get_price (likely other markets) by specifying US market via yfinance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides example queries ('AAPL price') and specifies data fields returned, implying use for US stock queries. Lacks explicit when-not or alternatives, but context from sibling names helps.
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 the burden. It mentions that codes can change, adding some context, but does not explicitly state read-only or non-destructive behavior, rate limits, or side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds value: purpose, examples, usage rule, alias. No unnecessary words. Well-structured with bullet points and warnings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool with an output schema, the description covers purpose, usage context, parameter examples, and alias. It is complete and leaves no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'query' as a string with no description. The description adds meaning by providing examples ('삼성전자', '005930', '알멕') and explaining it can be a name, code, or partial query, compensating for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool searches Korean stocks by name or code, with examples ('삼성전자', '005930'). It distinguishes from siblings as the primary search tool and mentions an alias (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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this tool first when the user provides a stock name without a code, warns against guessing codes due to possible delisting/reassignment, and provides clear when-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?
With no annotations provided, the description carries the full burden. It adds a key behavioral trait: the tool outputs a large payload (3,500 characters per stock, 78% token usage for 5 stocks), warning about token consumption. This goes beyond mere function and is valuable for agent planning. It does not mention read-only status or permissions, but for a simple read tool, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a bolded purpose, a warning with a sibling reference, usage context, and parameter details. Every sentence serves a purpose—no redundancy or fluff. It front-loads the primary function and then provides actionable warnings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter) and presence of an output schema, the description is largely complete. It mentions the 19-item scope and gives a token warning. It doesn't detail the output structure, but the output schema exists to cover that. It also doesn't explain how to interpret negative values or exceptions, but for this level of complexity, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'code', has zero schema description coverage. The description compensates by specifying '종목코드 6자리' (6-digit stock code) with an example '005930'. This adds essential format and example details beyond the bare schema, meeting the low-coverage baseline of 3 and exceeding it with concrete guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full set of financial indicators (19 items, annual/quarterly trends) for a single stock, using the bolded '전체' to emphasize scope. It explicitly contrasts with sibling get_financial_batch for multi-stock comparisons, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: '여러 종목을 비교하려면 `get_financial_batch`를 쓰세요' (use get_financial_batch for multi-stock comparisons) and mentions suitable queries (PER, PBR, 재무제표, etc.). This gives clear when-to-use and when-not-to-use instructions with a named 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?
No annotations are provided, so the description must disclose behavioral traits. It reveals defaults (market='KOSPI', count=50), maximum count (500), and unsupported value (ALL). This is adequate for a simple read tool. The description does not contradict any annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a purpose line followed by usage hints and parameter details. Each sentence adds value with no redundancy. The structure is front-loaded with the main action and key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (coverage of return values not needed), the description covers all necessary aspects: purpose, parameter details, constraints (ALL unsupported), and defaults. The sibling tools are numerous but this tool's niche (market cap ranking) is clearly defined, making it complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains the market parameter as accepting 'KOSPI' or 'KOSDAQ' with a default of 'KOSPI' and notes 'ALL' is unsupported. For count, it specifies default 50 and maximum 500. This adds significant meaning beyond the schema's type and default fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves top market capitalization stocks, using the verb '가져옵니다' (brings) and specifies the resource as '시가총액 상위 종목'. It provides usage examples ('대형주', '시가총액 TOP', '코스피 대장주') that distinguish it from sibling tools like get_change_ranking or get_volume_ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes example queries indicating appropriate use cases. It also explicitly states that the market parameter does not support 'ALL', which is a constraint. However, it does not provide explicit when-not-to-use guidance or compare with alternatives, though the purpose 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?
No annotations provided. Description discloses key behavioral trait: only extracts key rows (e.g., Total Revenue, Net Income). Does not mention auth or error handling, but for a read-only data tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two-sentence description followed by parameter list. Front-loaded with purpose, no wasted words. Uses examples effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists (no need to describe returns) and low complexity, the description covers purpose, parameters, and key behavioral note. Complete for a simple data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description fully compensates by explaining ticker as US ticker, statement_type allowed values (income/balance/cash_flow) and default, period allowed values (annual/quarterly) and default. Adds semantic meaning beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves US financial statements (income, balance, cash flow) with specific examples like 'AAPL 손익계산서'. It distinguishes from siblings like get_us_financials by focusing on statement types and key rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context via example queries, implying when to use (e.g., when user asks for income statement). Lacks explicit when-not-to-use or alternative tools, but the examples are sufficient context.
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 behavioral disclosure burden. It explains the data content (OHLCV candles), count limits (default 120, max 500), timeframe options, and clarifies that indicators are handled by a different tool. It does not go deeper into edge behavior, but the output schema exists and the disclosed behavior is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized and front-loaded, with the purpose stated first, followed by usage guidance and an Args section. It is slightly repetitive ("캔들차트 OHLCV" appears alongside "candlestick OHLCV" in the same sentence), but overall every major part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter chart tool with an output schema, the description is complete: it covers purpose, when to use, parameter semantics, limits, and sibling-tool boundaries. An agent has enough information to select and correctly invoke this tool without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter: code format with an example, timeframe valid values with Korean mappings, and count default/maximum semantics. This adds substantial meaning beyond the bare schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning OHLCV candlestick time-series data for a single ticker, listing exact fields (시가/고가/저가/종가/거래량). It gives concrete query examples and explicitly distinguishes itself from get_multi_chart_stats and get_us_chart, so an agent can tell which chart tool to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance with example phrases like "삼성전자 일봉" and "price history". It also names alternatives for other cases: get_multi_chart_stats for multi-stock period stats, get_us_chart for US time-series, and get_indicators when technical indicators are explicitly requested.
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 burden. It discloses a key limitation: the earnings surprise table only includes operating profit and net income, not sales. It does not mention permissions or side effects, but for a read tool that is acceptable. This adds meaningful 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: first a definition, then usage examples, a scope note, and an args section. Every sentence adds value, and it is not verbose. It is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, clear purpose) and that an output schema exists, the description is complete. It covers what the tool does, when to use it, its limitations, and its alternative. No important aspects are left unmentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the single parameter. It states the format (6-digit stock code) and provides an example ('005930'), adding meaning beyond the bare schema title 'Code'. This is sufficient for a single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool provides consensus data (analyst ratings, target prices) and earnings surprises relative to consensus. It lists example queries that should trigger this tool, and distinguishes from siblings by explicitly directing sales-related queries to get_financial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage triggers are given (e.g., 'target price', 'consensus', 'earnings surprise'). The description clearly says when NOT to use it (for sales figures) and names the alternative tool (get_financial), providing a clear decision boundary.
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, but the description extensively explains output semantics, including caveats like trade_value_est being an estimate and data_basis possibly being in_progress_bar. It does not explicitly state the tool is read-only, but the query-oriented nature and lack of side effects are implied. The detailed field explanations compensate for missing explicit 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy due to detailed field semantics, but it is well-structured with sections and bullet points. Each piece of information is relevant and aids comprehension, though some repetition of Korean terms (e.g., '봉') could be streamlined. Overall, it is informative without excess filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, usage conditions, parameter details, output field meanings, and data timing caveats. It also distinguishes from chart visualization and notes the tool's suitability for numeric comparisons. This provides a comprehensive understanding necessary for correct usage without external references.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that explains each parameter: code, days, params, include, timeframe, with defaults and allowed values. For example, it specifies that 'include' accepts a list of indicator keys and provides the default, and 'params' allows overriding indicator-specific settings like RSI period. This fully clarifies parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides technical indicators (이평선, RSI, MACD, 볼린저, 스토캐스틱) and judgments. It also explicitly distinguishes its purpose from chart visualization, specifying it should be used for numeric comparisons, making the tool's intent 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: call only for screening, condition filtering, or status judgment requiring numeric comparison, and not for visualization (pointing to get_chart). It also provides field-level interpretation notes, such as 'latest_date' meaning the last bar, not today, which helps users apply the tool correctly.
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 provided, but the description discloses important behavioral traits: it performs a server-side join of ranking and flow data to save tokens and time, and notes that larger top_n values slow performance (500≈20~50 seconds). This is comprehensive for a read-only screening 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a title, brief summary, example usage, and an Args section. While it is somewhat lengthy, it is organized and front-loaded with the main purpose. Minor redundancy could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters all explained in detail, an output schema exists (providing return structure), and no nested objects, the description covers input semantics and behavioral context (performance, server-side join). It is complete enough for an AI agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining every parameter in Korean: top_n (default 100, max 500, slower when larger), market (KOSPI/KOSDAQ/ALL), foreign_days (recent N days all net buy by foreigners, 0=no apply), inst_days (similar), exclude_etf (default True), sort_by (trade_value/volume). This adds all necessary meaning beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool screens stocks based on trading volume/value and foreign/institutional buying streaks. It specifies it's dedicated to screening and joins ranking with flow data server-side, distinguishing it from siblings like get_flow or get_volume_ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example queries like '거래대금 상위 중 외국인·기관 동반 매수' and '이틀 연속 수급 들어온 종목', clearly indicating when to use this tool. However, it does not explicitly contrast with sibling tools or state when not to use it, which would elevate it to 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 are provided, so the description carries the full burden. It discloses that the tool returns a list of matched stocks and that if multiple matches exist, the user should be asked to confirm. It implies a read-only lookup operation. While it does not explicitly state authentication or rate limits, the behavioral traits are adequately transparent for a simple lookup 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and well-structured, with a clear title, warnings, and bullet-pointed parameter and return descriptions. It is front-loaded with the purpose. While a bit lengthy, every sentence adds value, including usage guidelines and examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter), the presence of an output schema, and no annotations, the description is complete. It covers purpose, when to use, parameter meaning, and return format (list of matches with user confirmation if multiple). No additional information is necessary for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to the 'query' parameter beyond the schema, which has no description. It explains that the query can be a stock name in Korean/English or a 6-digit code, and provides examples. With 0% schema description coverage, the description fully compensates and makes the parameter clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '종목코드조회 (stock lookup) — 한국 주식 종목명/코드 조회 전용 도구', which translates to 'stock code lookup — dedicated tool for searching Korean stock names/codes.' It also distinguishes itself from siblings by noting it is an alias of 'search' and provides a specific use case for when to use it (when only the name is known), differentiating from other tools like get_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: '종목명만 있고 6자리 코드를 모를 때 이 도구를 먼저 호출해야 합니다.' (When you only have the stock name and don't know the 6-digit code, you must call this tool first.) It also warns against guessing codes and explains the consequence of using wrong codes in other tools, providing clear usage guidance.
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 discloses edge-case behavior: unanalyzable windows return a validation status/code, missing data is not shown as 0% or zero net trading, and non-trading days shift to the next trading day. This goes beyond a simple operation summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into purpose, usage context, behavioral caveats, and parameter details. Every sentence carries operational value, and the final Args block is compact and consistent with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no annotations, and no schema descriptions, the description covers purpose, usage, edge cases, and parameter semantics thoroughly. An output schema exists, so return-value details are not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully: it explains code format with an example, accepted event_date formats, and before/after defaults and maximums. This adds meaning the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: sorting price/volume/flow reactions before and after a given event_date. It clearly names the resource (event reactions) and scope (time-axis alignment around disclosures), and differentiates itself by stating it is for temporal alignment, not causal or buy/sell judgment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to pass disclosure receipt dates from DartLens scan_earnings_season/list_disclosures and notes holiday handling. It also states when not to use it ('원인 단정·매수/매도 판단 아님'), but it does not name alternative sibling tools, so it falls just 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?
Without annotations, the description carries the burden. It discloses that this tool is optimized for token efficiency (citing a measured 78% token usage), and mentions the input limit (max 30 codes). However, it does not explicitly state it's read-only or describe error handling, but for a data retrieval tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first line defining purpose, followed by usage guidance and a concise Args section. Each sentence adds value—no fluff, and the distinction from get_financial is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description is complete: it explains when to use it, what it returns, the parameter format, and how it differs from the sibling tool. No gaps remain for the agent to misunderstand.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines codes as an array of strings, but the description clarifies it must be a list of 6-digit stock codes and caps at 30 items. This adds critical validation and usage context, making the parameter meaning clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: providing a table of core financial metrics (PER/PBR/ROE, etc.) for multiple stocks. It also explicitly distinguishes it from get_financial by contrast ('한 종목의 **전체** 지표... 그때만 get_financial을 쓰세요'), making its purpose unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance with concrete examples like comparing multiple stocks or identifying undervalued ones, and explicitly names the alternative tool (get_financial) for single-stock deep dives. It also explains why (token efficiency) which is actionable.
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 maximum of 30 codes and the read nature (fetching basic info), but doesn't explicitly state it is read-only or mention rate limits. Still, it provides actionable behavioral hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but dense: first sentence states function, followed by typical queries, efficiency note, and necessity. Parameter explanation is clear. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (bulk fetch with one parameter) and the presence of an output schema, the description covers all needed aspects: usage, constraints, and value over alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains the 'codes' parameter: it's a list of stock codes, max 30, with examples. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches basic info (price, change, volume) for multiple stocks at once. It specifies the resource and distinguishes itself from repeated calls to get_price, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use for bulk lookup and comparing screening results, and notes token efficiency over multiple get_price calls. Though it doesn't list when not to use, the context is strong enough for an AI 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a single point-in-time snapshot, not history, and explains how NXT-related stocks are handled by showing KRX regular market data by default and appending NXT data separately without mixing exchanges. Some edge behaviors like error cases or delayed quotes are not covered, but the description is substantially 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, uses compact warning-style reminders, and only includes necessary caveats such as multi-stock, chart/history, and NXT behavior. Every sentence adds relevant value and the structure is scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has one parameter, an output schema, and no annotations, the description is sufficiently complete. It covers purpose, scope, exchange behavior, parameter format, and clear alternatives for related tools, so an agent has enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines code as a required string, but the description supplies the essential semantic detail: '종목코드 6자리 (예: "005930")'. This fully compensates for the 0% schema description coverage and removes ambiguity about parameter format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines get_price as a current-price snapshot for a stock, including today's OHLC and volume. It also explicitly distinguishes it from sibling tools like get_multi_stocks and get_chart, making the purpose and scope 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance with example queries like '삼성전자 지금 얼마', and gives clear alternatives: '종목이 2개 이상이면 get_multi_stocks를 쓰세요' and '차트/히스토리 필요 시 get_chart 사용'. This directly helps an agent select between competing tools.
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 to rely on, the description fully discloses key behavioral traits: it only reads existing call logs and cache (no new network calls, hence fast), works even without an active license, and is intended for lightweight status checks. This goes well beyond what the empty parameter schema reveals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense, with each sentence serving a purpose: summary of output, use case, network/cache behavior, license exemption, and pointer to deeper diagnostics. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no annotations) and the presence of an output schema, the description covers all necessary context: what it returns, when to use it, how it behaves, and what to do for more thorough investigation. It is fully complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema's properties object is empty, so schema coverage is effectively complete. The description doesn't need to explain parameter meanings. The baseline of 4 for a no-parameter tool is appropriate, as there is nothing to elaborate on.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific summary: it reports version/license/market status/recent success-failure/cache writability at a glance. This clearly identifies the tool's resource and function, and it stands apart from sibling market-data tools, which focus on stocks, charts, and financials rather than system health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use 'when lightly checking during conversation whether there's a problem,' and contrasts itself with deeper diagnosis by directing users to the stocklens-doctor terminal command. It also distinguishes its behavior from other tools by noting it bypasses the license gate, giving 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.
Behavior5/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 transparently discloses that keyword filtering matches only the ETF name, not holdings, and that category values are restricted to a listed enum. This goes beyond simple operation definitions and gives actionable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise purpose line followed by parameter definitions and usage examples. Every sentence earns its place, and the length is appropriate for the complexity. No fluff or repetitive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no schema descriptions, no annotations, but the description covers all aspects: purpose, parameter semantics, edge cases, and alternatives. An output schema exists, so return value details are not needed. The description is fully complete for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining every parameter: the category allowed values, keyword semantics with examples, sort_by options with Korean labels, and limit defaults/maximum. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'ETF 전체 목록 조회' (retrieve full ETF list) with category and keyword filtering. It distinguishes itself from sibling tools like get_etf_info (which retrieves details of a single ETF) by implying this is the list-level 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: for 'OO 테마 ETF 뭐 있어' queries, use keyword directly rather than guessing category. It also explains when this tool is insufficient (searching for ETFs holding a specific company not in the name) and directs the user to get_etf_info as an alternative.
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 full burden. It discloses token consumption warning, the one-at-a-time constraint, mode behavior differences, the fact that some PDFs are image-based and unreadable, and the failure handling (informing user and providing link). Extremely 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Despite being long, every sentence serves a purpose. The mode table condenses essential info, warnings are clearly flagged, and the structure (purpose, constraints, mode table, rationale, edge case, args) is logical and easy to scan. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three modes, one-at-a-time constraint, token limits, PDF rendering issues) and the absence of annotations, the description covers all necessary context: when, why, how, and what to expect. It even explains the rationale for summary mode based on report structure. The presence of an output schema covers return values, but the description fully prepares the agent for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does: the Args section explains each parameter (nid, mode, max_chars) with types, defaults, valid values (including Korean synonyms), and when to use each. Adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads one report's PDF content ('증권사 리포트 한 건의 PDF 본문을 읽어옵니다'), and distinguishes itself from sibling get_reports which provides lists and summaries. It also specifies the exact scope (one report at a time) and the use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use this tool vs alternatives: '목록·목표가·짧은 요약은 get_reports로 충분하고, "이 리포트 자세히"...처럼 한 건을 깊게 볼 때만 쓰세요' and provides a table of trigger phrases for each mode. Clearly excludes casual list browsing.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Johnhyeon/stocklens-mcp'

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