tossinvest-mcp
Server Quality Checklist
Latest release: v0.4.5
- Disambiguation5/5
Each tool targets a distinct resource or action, with clear descriptions separating singular/plural pairs (e.g., toss_get_order vs toss_get_orders) and stock vs market indicator variants. No two tools appear to overlap in purpose.
Naming Consistency5/5All tools follow a consistent toss_<verb>_<noun> pattern in snake_case, with verbs like get, prepare, submit, and resolve. The prepare family is uniformly named (prepare_order, prepare_conditional_order, etc.), making the set predictable.
Tool Count2/5At 29 tools, the set exceeds the 25-tool threshold for 'too many.' While the domain is broad, several tools could be consolidated (e.g., singular/plural getters, separate indicator tools), making the surface feel heavier than necessary.
Completeness5/5The tool surface covers the full lifecycle of trading: market data, account positions, order placement (regular and conditional), order modification/cancellation, and auxiliary data like commissions and market calendar. No obvious gaps for a stock trading MCP.
Average 4.1/5 across 29 of 29 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint and openWorldHint annotations and contains no contradictions. However, it adds minimal behavioral context beyond what annotations already provide—no mention of pagination, rate limits, or other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to stating the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with good annotations, the description states the return type and intervals, which is adequate. However, it omits pagination details, sibling differentiation, and any guidance on symbol resolution, leaving gaps that the schema partially fills.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the interval parameter ('1-minute or daily') and the output type (OHLCV), but it does not explain count or before semantics. With schema description coverage at 50%, the description only partially compensates for the undocumented before parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Returns 1-minute or daily OHLCV candles for a market indicator.' It clearly distinguishes this from generic candle tools by mentioning 'market indicator,' but it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor are exclusions or prerequisites mentioned. The schema's symbol description mentions calling toss_resolve_symbol first, but the tool description itself lacks any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds minimal context beyond the title—'value trends' and the market scope—but does not disclose return format, pagination, or default behavior, which would strengthen transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately states the action and scope, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no usage guidance, the description is too sparse for a data-retrieval tool. It does not mention what a 'trend' response looks like, how count/until affect results, or when to prefer a sibling tool, leaving important context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'until' is described). The description does not compensate by explaining count, interval, or how they shape the returned trends. While enum values hint at meaning, the description adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Returns investor trading value trends for KOSPI or KOSDAQ' uses a specific verb and names the exact resource and scope. It clearly distinguishes this from the sibling toss_get_stock_investor_trading tool by identifying market indices rather than individual stocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to use this tool versus alternatives. It only states the market scope (KOSPI/KOSDAQ), but does not mention the stock-level sibling or any conditions for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which the description confirms. The description adds the qualifier 'live', indicating real-time data, but does not disclose other behavioral traits such as data delay or the number of levels returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action and contains no unnecessary words. It is perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and annotations, the description is fairly complete. It states the output (ask and bid levels) and input types, but does not specify the depth of the order book or provide usage guidance relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with a detailed parameter description including examples and a reference to toss_resolve_symbol. The tool description itself adds no extra parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live ask and bid levels for a Korean stock code or US ticker, using a specific verb and resource. It does not explicitly distinguish itself from sibling tools, but the order book scope is unique enough to be understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like toss_get_price or toss_get_candles. The description simply states what it does without any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the read-only nature is established. The description adds that data is daily and limited to Korean stocks, which is useful context. However, it does not disclose return format, pagination, or any other behavioral traits beyond the annotations, so it only partially enriches the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains no fluff or redundancy. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and full schema coverage, but there is no output schema. The description does not explain what the response rows will contain (e.g., net buying amounts, volumes) or how pagination via 'count' works, leaving gaps for an agent expecting structured output. It is adequate for a basic read-only tool but not fully informing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters (count, until, symbol), including formats and constraints. The description adds no parameter-specific meaning beyond what the schema already provides, so it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns daily Korean-stock trading trends for specific investor categories (retail, foreign, institutional, other). It uses a specific verb 'Returns' and a clear resource, making the purpose unambiguous and distinguishable from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description does not mention alternatives, exclusions, or clarify when to use this tool over its sibling 'toss_get_market_investor_trading'. The only implicit hint is the 'stock' in the name, but no explicit usage context is 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?
Beyond the annotations (readOnlyHint, openWorldHint), the description adds no behavioral details such as data freshness, limit behavior, or return format. It merely restates the tool's purpose without disclosing side effects, dependencies, or formatting specifics. Since annotations already indicate a safe read operation, the description should add context but doesn't.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource. It is free of filler and conveys the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain what the tool returns (e.g., a list of executions with price/time) and note that 'count' is an optional limit. It does neither, leaving the agent to infer response structure and behavior from the tool name alone. Annotations cover safety but not functional completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a detailed description for 'symbol' (Korean code or US ticker) and a resolution hint. The tool description only echoes this without adding new information about the 'count' parameter, whose meaning is only implied. With 50% schema coverage, the description does not fully compensate for the undocumented 'count' parameter, but 'count' is fairly self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it returns recent executions (trades) for a Korean stock code or US ticker. This specific verb-resource pair distinguishes it from sibling tools like toss_get_price (current price), toss_get_candles (historical candles), and toss_get_orders (order status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool—when you need recent executions—and the schema adds a useful hint to call toss_resolve_symbol if only a company name is known. However, it does not explicitly exclude alternatives or explain when not to use this tool, missing the top tier of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds behavioral context by specifying the data frequency ('daily') and asset scope ('Korean-stock'), which helps set expectations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that conveys the core function with no wasted words. It is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only data retrieval tool, the description covers the essential output (volume, value, ratio) and scope. However, it lacks any guidance on usage context or alternatives, and with no output schema, some details about the response structure are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not elaborate on the parameters beyond what the schema already provides; it only describes the returned data fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns') and resource ('daily Korean-stock short-selling volume, value, and ratio'), which clearly identifies the tool's function. It distinguishes itself from sibling market data tools by focusing on short-selling metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as toss_get_stock_investor_trading or toss_get_recent_trades. There are no explicit use cases, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states "Nothing reaches the market from this call" and describes the token as single-use with 60-second expiry, but the annotations declare destructiveHint=true, implying destructive side effects. This directly contradicts the description's explicit claim of no market impact, so the transparency score is 1 due to the annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the core action, then presents alternatives, safety behavior, and workflow. Every sentence adds essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior (preview, nothing reaches market), token lifecycle, workflow, and sibling distinctions. However, with no output schema, it does not detail the structure of the preview (e.g., estimated price, fees), leaving a minor gap in return-value expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (symbol, side, orderType, price, quantity, orderAmount, timeInForce) having a detailed explanation. The tool description itself adds no parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Previews a NEW market or limit order to buy or sell one stock immediately." It explicitly differentiates from siblings by naming toss_prepare_conditional_order for trigger-based orders and toss_prepare_order_modify/cancel for existing orders, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: "For trigger-based orders use toss_prepare_conditional_order; to change or withdraw an order that already exists use toss_prepare_order_modify or toss_prepare_order_cancel." It also clearly outlines the workflow: show preview, obtain approval, pass token to toss_submit_prepared_order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Nothing reaches the market from this call: it only validates the request and returns a preview plus a confirmation token,' but the annotations declare destructiveHint: true. This is a direct contradiction: the tool is described as non-destructive while the annotation implies destructive effects. No other behavioral traits beyond the contradictory statement are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused paragraph of four sentences. It front-loads the main purpose, then covers prerequisites, alternatives, side effects, and next steps without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a preparation tool with no output schema, the description covers the core workflow: validation, preview, token, expiry, and submission. It doesn't describe the preview's contents or return format, but it's sufficient for an agent to understand the tool's role in the order modification process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of parameter meanings, including conditional requirements. The description adds a little context (e.g., 'only the listed fields change,' 'Find the orderId with toss_get_orders'), but these are minor additions. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool previews a change to an existing open regular order, specifying the fields (quantity, price, order type). It also distinguishes from the sibling tool toss_prepare_conditional_order_modify by explicitly saying to use that for conditional orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: find orderId via toss_get_orders with status 'OPEN', use a different tool for conditional orders, and follow the workflow of showing the preview, obtaining approval, then submitting via toss_submit_prepared_order. This clearly directs the agent.
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?
The description mentions a key behavioral trait (multiple candidates when 'exact' is false), but the input schema does not include an 'exact' parameter, and additionalProperties is false. This references a non-existent parameter, which is misleading. The readOnlyHint annotation is consistent with 'Finds', but the description does not disclose return format or behavior when no match is found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and an example, followed by a critical behavioral note. No wasted words, easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers purpose, example, and ambiguity handling. But it references a parameter ('exact') not present in the schema, and gives no guidance for unmatched queries or error cases. This makes it incomplete and potentially confusing for an agent relying on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single 'query' parameter with examples. The description adds a practical example mapping '삼성전자' to 005930, reinforcing schema semantics. However, the mention of 'exact' could imply an undocumented parameter, which slightly detracts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Finds the Toss Securities symbol for a company name or ticker' with a concrete example. This distinguishes it from sibling tools like toss_get_price or toss_get_orderbook, which focus on market data or order management, not symbol resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: whenever a symbol is needed from a company name/ticker. It also gives behavioral guidance for ambiguous matches ('ask the user which one instead of picking one yourself'), though it doesn't explicitly contrast with alternatives. Since no sibling tool does symbol resolution, the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and dynamic nature are covered. The description adds the scope of 'Korean and US stock' but does not disclose other behavioral traits such as return format, rate update frequency, or cost calculation nuances. With annotations present, this modest addition warrants a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words or filler. It is front-loaded with the verb 'Returns' and immediately specifies the resource. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is mostly sufficient for an agent to invoke it. However, it does not specify the exact return format (e.g., whether it returns a list or grouped objects), but for a simple commission schedule retrieval tool, the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain parameter meanings. The baseline for zero-parameter tools is 4, and the description adequately covers the tool's purpose without needing parameter elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Returns' and clearly identifies the resource as 'applicable Korean and US stock trading commission schedules'. This distinguishes it from all sibling tools, which focus on orders, prices, candles, or market data, none related to commissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when commission schedules are needed, but it does not explicitly state when to use it versus alternatives. Since no sibling tool covers commissions, the context is implicitly clear, but there is no explicit guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description doesn't need to restate safety. It adds value by mentioning adjacent business days and the KR/US market scope, but it doesn't disclose return format, timezone handling, or edge cases. This is acceptable given the annotation coverage but leaves room for more detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the verb front-loaded, no filler, and every word contributes to understanding the tool's function. It is appropriately sized for the simple operation it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool with clear annotations and a simple schema, the description is sufficiently complete. It doesn't specify return structure, but that's not required given the absence of an output schema and the low complexity. A slight gap is the lack of details on what 'adjacent business days' means in the response, but overall context is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 'date' with format and meaning, and 'market' has an enum. The description adds context by naming the markets and implying date is used to compute adjacent business days, but it doesn't explicitly explain parameter behavior beyond that. With 50% schema coverage, the description partially compensates but doesn't fully clarify the interplay between date and market.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and clearly identifies the resource ('session and holiday information for the Korean or US market'), distinguishing it from sibling data-fetching tools. It aligns with the title and leaves no ambiguity about the tool's 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when market session/holiday info is needed) through its clear scope, but it does not explicitly state when not to use it or name alternative tools. Sibling names suggest a broader ecosystem, but no direct comparison is made.
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 annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read. The description adds value by enumerating the specific warning types returned, offering behavioral context beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists all key warning categories without any filler. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with good annotations and full schema coverage, the description is nearly complete. It clearly communicates the type of data returned, though it omits details about the return structure or possible empty results—acceptable given the low complexity and lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of the single parameter (symbol) with detailed guidance on format and resolution, so the baseline is 3. The main description does not add any parameter-specific meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Returns' and clearly identifies the resource as stock warnings, enumerating four distinct warning categories (investment cautions, liquidation trading, volatility interruption, warrant warnings). This is sufficiently specific to distinguish it from sibling tools like toss_get_price or toss_get_orderbook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no explicit when-to-use guidance, exclusions, or alternative tool references. The schema's symbol description mentions calling toss_resolve_symbol first for company names, but the main description does not offer usage context beyond a plain return statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Nothing reaches the market from this call: it only validates...' but annotations include destructiveHint: true. This is a direct contradiction: the description implies non-destructive behavior while the annotation flags destructiveness. Therefore, score is 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense with no fluff. Every sentence contributes: definition, order type semantics, alternative, validation behavior, workflow, and token details. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple order types, nested leg objects, no output schema), the description covers essential aspects: it returns a preview and token, explains token single-use and 60-second expiry, and describes the submission flow. Broad enough 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter already described. The description adds meaningful context beyond the schema by explaining the behavioral differences between SINGLE, OCO, and OTO, and how orderType interacts with legs. This supplements the structured field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: previews a NEW conditional order that remains dormant until trigger price is reached. It also differentiates from the sibling toss_prepare_order for immediate execution. Specific enough to distinguish from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names toss_prepare_order as the alternative when execution is needed right away. Also outlines the full workflow: show preview to user, get approval, pass token to toss_submit_prepared_order, and notes token expiry. This gives clear when-to-use and how-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description directly contradicts the annotations. Annotations declare destructiveHint: true, but the description states 'Nothing reaches the market from this call: it only validates the request and returns a preview plus a confirmation token.' This is a clear annotation contradiction, so the score is 1 regardless of additional behavioral details like token expiry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the primary purpose. It covers the preview nature, token handling, expiry, and alternatives in a compact set of sentences without redundancy. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a two-step cancellation flow) and the absence of an output schema, the description is remarkably complete. It explains the token's single-use nature, 60-second expiry, the need for explicit user approval, and the next step (toss_submit_prepared_order). It also covers the key prerequisite of finding the order with a specific status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema by specifying the orderId must have status 'OPEN' and come from toss_get_orders, which is not explicitly in the schema's parameter description. This helps the agent select and validate the correct parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Previews the withdrawal of an EXISTING open regular order so that none of its remaining quantity can fill.' It also distinguishes itself from siblings by explicitly pointing to toss_prepare_conditional_order_cancel for conditional orders and toss_submit_prepared_order for the actual submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Find the orderId with toss_get_orders (status OPEN)' and 'Use toss_prepare_conditional_order_cancel for conditional orders.' It also outlines the complete workflow, including obtaining explicit approval and passing the token to toss_submit_prepared_order, giving clear alternatives and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe read nature is known. The description adds valuable constraints: interval options (1m/1d) and a maximum of 200 candles per call, which go beyond the annotations and inform the agent about limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and immediately adds key constraints. Every word contributes value; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only candle listing tool with high schema coverage, the description is sufficient. It does not detail the return structure, but no output schema exists and the phrase 'OHLCV candles' implies the expected data shape. Given the moderate complexity, this is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions interval allowed values and the 200-candle cap, but these are already present in the schema (enum and maximum). It adds no new semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning OHLCV candles for a symbol, with an explicit purpose of trend and volatility analysis. This distinguishes it from sibling tools like toss_get_price (single price) and toss_get_recent_trades (trades).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the tool is for trend and volatility analysis, providing clear context on when to use it. However, it does not explicitly mention alternatives or when not to use it, though the purpose implication is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds a small amount of behavioral context by explaining the tool lists trigger-based orders and that the output includes conditionalOrderId, but it does not discuss details like pagination behavior or response format. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loads the primary purpose, and then provides useful guidance on usage and sibling differentiation. No wasted words, and the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with well-documented parameters and annotations, the description is sufficient. It includes purpose, usage context, and sibling differentiation. It does not explain the return format, but the mention of 'conditionalOrderId' hints at the key output, and the lack of an output schema raises the bar slightly. Still, the coverage is strong given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for all four parameters with detailed descriptions, so the baseline is 3. The description adds the phrase 'filtered by status' which aligns with the required status param but does not provide semantics beyond what the schema already explains. Minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Lists conditional (trigger-based) orders in the account, filtered by status.' It also differentiates from the sibling toss_get_orders by stating that regular orders are listed separately, and clarifies that the tool is used to find conditionalOrderId for modify/cancel preparations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: it says to use this tool to find the conditionalOrderId needed by specific sibling tools, and notes that regular orders are handled by toss_get_orders. This provides clear context on when to use the tool and an alternative, satisfying the top criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds valuable detail about the return content (current status and every partial execution), which goes beyond the generic read-only hint and helps the agent understand the tool's output scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both purposeful: the first states the action and key details, the second gives the usage context. No redundant phrasing or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no output schema, the description adequately explains what the response contains and when to use it. It could be slightly more explicit about what 'regular order' excludes (e.g., conditional orders), but the sibling list provides context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage, describing orderId as returned by toss_get_orders or toss_submit_prepared_order. The description does not add extra meaning beyond this, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets one regular order with its current status and partial executions. The use of 'one regular order' distinguishes it from toss_get_orders (plural) and conditional order tools, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use it to confirm what actually filled after submitting an order.' This gives explicit guidance on when to use the tool, though it does not explicitly mention alternatives or when not to use it, which would warrant a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive and open-world hints, and the description adds valuable behavioral context: the requirement for explicit user confirmation, single-use token, and 60-second expiration. This goes beyond the structured annotations and clarifies the action's safety-critical 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every sentence adds essential information. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two parameters, an output schema is absent, and annotations cover safety, the description is sufficiently complete. It covers the critical preconditions and side-effect nature, though it does not describe return values or error behavior, which is acceptable for this low-complexity action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to explain basic parameter semantics. It does reinforce the binding between the token and the exact preview, which aligns with the schema but adds no new meaning beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Places') and resource ('previously prepared order'), clearly distinguishing this submit action from the sibling prepare/get tools. It precisely identifies what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit precondition: call only after explicit user confirmation of the exact preview in the conversation. It also notes the token's single-use nature and 60-second expiry, which imply when not to call. It does not name alternatives, but no direct alternative submit tool exists 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?
Annotations already declare readOnlyHint=true, covering the safety profile. The description adds useful context about the relationship to holdings but does not disclose additional behavioral traits such as response format or default currency behavior, which the schema partially covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no redundancy. The core action is front-loaded, and the second sentence provides essential complementary information without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, the description and schema together fully explain what it returns and when to use it. The note about computing total assets with toss_get_holdings makes the context complete despite the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single optional 'currency' parameter with an enum and explicit note that omitting it fetches both KRW and USD. The description adds no additional parameter-level meaning, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Returns available cash' with the resource 'Toss Securities account,' clearly conveying the tool's function. It distinguishes itself from the sibling toss_get_holdings by explicitly stating that holdings excludes cash.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence provides explicit usage guidance: 'toss_get_holdings excludes cash, so call this too when computing total assets.' This names a concrete scenario and the complementary sibling tool, effectively communicating when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds valuable behavioral detail about the response—whether the trigger has fired and what each leg is doing—which goes beyond the structured data and clarifies what the caller will learn.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two crisp sentences: the first states the action and scope, the second provides a usage tip. No filler or redundant wording—every phrase contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple detail-fetch tool with one well-documented parameter and no output schema, this description conveys the essential return aspects (full detail, trigger state, leg actions). It is complete enough for an 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter with provenance ('as returned by toss_get_conditional_orders or by toss_submit_prepared_order'), so the description does not need to repeat it. With 100% schema coverage, the baseline of 3 is appropriate; the description adds no extra parameter nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Gets') with a clear resource ('one conditional order') and adds detail about what 'in full' means—trigger status and leg behavior. This distinguishes it from the plural listing tool (toss_get_conditional_orders) and the regular order detail tool (toss_get_order).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives explicit use context: 'Use it to check on an armed condition before modifying it.' This clearly states when to invoke the tool, though it does not explicitly name alternatives or when-not scenarios, which keeps it just below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds a meaningful constraint that symbols must be 'documented' (i.e., valid indicator symbols), which hints at validation behavior. It does not describe error handling, response format, or other runtime behavior, but for a simple read tool with annotations, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, front-loaded sentences with no fluff. The first sentence states the core function, and the second gives a direct usage instruction. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with annotations and no output schema, the description covers what the tool does, what input it expects, and a key constraint. It is sufficient for an agent to select and invoke the tool correctly in most expected scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% at the property level, so the description must compensate. It explains that the symbols parameter refers to market indicators and must contain 'documented' symbols, adding semantics beyond the raw schema. The schema's item descriptions already cover code formats (Korean 6-digit or US ticker) and the resolve_symbol prerequisite, so the description adds the indicator-specific context that was missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns current prices for market indicators, naming specific examples like KOSPI and KOSDAQ. This distinguishes it from sibling tools like toss_get_price (for individual stocks) and toss_get_market_indicator_candles (historical 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: pass one or more documented indicator symbols to get current prices. It also includes a symbol-resolution prerequisite through the schema. However, it does not explicitly contrast with alternatives like toss_get_market_indicator_candles or toss_get_price, so it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it explains the tool's role in obtaining order IDs for subsequent modify/cancel operations and clarifies the regular-vs-conditional order distinction. It doesn't add details on pagination or other traits, but the schema covers those.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the core purpose and scope, the second provides usage guidance and sibling differentiation. Every sentence earns its place, and it is front-loaded with the primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description explains the primary use case (finding orderId, checking fills) and the key distinction from conditional orders. Combined with the detailed schema and annotations, the agent has enough context to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83% (>80%), so the schema documents parameters well. The description adds no parameter-specific semantics beyond 'filtered by status', which is already in the schema. Baseline 3 applies as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Lists' with a clear resource ('regular orders in the account') and scope ('filtered by status'). It distinguishes itself from sibling tools by explicitly noting that conditional orders are handled separately by toss_get_conditional_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: to find the orderId needed by toss_prepare_order_modify and toss_prepare_order_cancel, or to check whether an order filled. It also gives an exclusion by pointing to the conditional orders alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description adds valuable behavioral context beyond that: it specifies the accepted formats for Korean and US symbols, and notes that both can be mixed in a single call. This is useful information for the agent to form correct requests, though it does not describe the output format or any error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three sentences, each serving a distinct purpose. It is front-loaded with the core purpose, then format rules, then a prerequisite alternative. No redundant or generic phrases are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple read-only tool with a single parameter and no output schema, the description covers the essentials: what it does, valid input formats, mixing behavior, and an important prerequisite step. It doesn't state the return structure explicitly, but 'Fetches current prices' strongly implies the return value. Slightly more detail on the response shape would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides an example ('['005930', 'NVDA']') and minimal description. The tool description enriches this by explicitly stating the Korean/US code convention and that mixing is allowed. This is meaningful additional meaning that helps the agent populate the 'symbols' parameter correctly, going beyond the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Fetches current prices from Toss Securities', which clearly states the verb and resource. It also explains the symbol format (Korean 6-digit codes vs US tickers), effectively distinguishing this from sibling tools like toss_get_candles or toss_get_orderbook by focusing on 'current prices'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (when you have Korean codes or US tickers and need current prices) and explicitly points to an alternative: 'If you only know the company name, call toss_resolve_symbol first.' However, it does not explicitly exclude other scenarios or contrast with sibling tools that might also return price-related data, so it stops short of being fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds meaningful context by defining the return type as a leaderboard and clarifying the scope (screening today's activity). It doesn't contradict annotations and enriches behavioral understanding beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first states the core function, the second provides a crucial contrast with a sibling tool. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters and no output schema, the description conveys the essential context: it returns a leaderboard, covers specific markets and metrics, and directs alternative usage appropriately. The lack of output schema is partially offset by the clear 'leaderboard' description, but some details (e.g., sorting direction or exact return structure) are left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description's mention of 'traded value, traded volume, or price change' maps to the type enum but adds little beyond the schema's own descriptions. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool ranks Korean or US stocks by specific metrics (traded value, volume, price change) for screening. It explicitly distinguishes itself from toss_get_price by clarifying it returns a leaderboard, not data about a specific stock.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'for screening what is active today' and directly names the alternative (toss_get_price) for when a user already picked a stock. This is clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds valuable behavioral context: 'Quotes expire in about five minutes, so do not cache the result.' This goes beyond the annotations and helps the agent avoid stale data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two tight sentences: the first states the core function and default, the second provides the use case and a critical time-sensitivity warning. Every sentence earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with only two optional parameters and no output schema, the description fully covers what the tool returns, the default behavior, the intended usage, and a caching caveat. Given the low complexity and strong annotations/schema, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with descriptions and enums, giving 100% coverage. The description adds meaning by explaining the conversion context (USD positions to KRW), which clarifies how baseCurrency and quoteCurrency relate. This extra context elevates the score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Returns the Toss Securities FX rate', and further clarifies the default pair USD->KRW. This clearly distinguishes it from sibling tools, as it is the only exchange-rate tool among the listed siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context on when to use this tool: 'Use it to convert USD positions to KRW.' This gives a clear use case. It does not name alternatives, but given the unique purpose among siblings, 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?
Given the annotations (readOnlyHint=true, openWorldHint=true), the description adds context by emphasizing 'actual positions' and the freshness advantage over hand-maintained files. It does not disclose return format or potential caveats, but the annotations already set expectations for safety, and the added context is valuable beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, highly concise, and directly informative. The first sentence states the core function, and the second provides actionable guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description provides enough context to select and invoke the tool correctly. It covers what is returned, where it comes from, and why this source is preferred, making the tool self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is an empty object. The baseline for 0 params is 4, and there is no need for parameter-related explanation. The description adds no parameter semantics, but none are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and identifies the exact resource (positions and P&L in the Toss Securities account). It clearly differentiates from hand-maintained portfolio files, and the resource is distinct from sibling tools like toss_get_orders or toss_get_buying_power, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: when you need actual positions and P&L, and it advises preferring it over hand-maintained portfolio files due to potential staleness. It does not, however, contrast with sibling getter tools, so exclusion of alternatives is limited but adequately covered for the scenario mentioned.
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?
The description goes far beyond annotations: it explicitly states 'Nothing reaches the market from this call: it only validates the request and returns a preview plus a confirmation token,' and discloses that the token is single-use and expires in 60 seconds. It also warns that every field is replaced, preventing accidental partial updates. This adds significant behavioral context beyond the destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Seven sentences, each carrying essential info: purpose, replacement semantics, symbol restriction, ID lookup, non-execution, workflow, and token expiry. No fluff or repetition; the description is front-loaded with the core purpose and then systematically adds constraints and instructions. Appropriately detailed for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, nested objects, no output schema), the description covers all necessary context: what to modify, constraints, how to get prerequisites, side effects, and the exact post-approval workflow. The absence of an output schema is compensated by mentioning the preview and confirmation token, which is sufficient for the agent to select and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already described in detail (enums, patterns, conditional requirements). The description adds a global rule ('Every field is replaced') that informs parameter usage but doesn't elaborate on individual parameters beyond what the schema provides, so it stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description's first sentence clearly states the tool 'previews a change to an EXISTING conditional order that has not triggered yet' and enumerates modifiable fields (trigger prices, legs, quantity, expiry). This distinguishes it from siblings like toss_prepare_conditional_order (creation) and toss_prepare_conditional_order_cancel (cancellation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: find the ID via toss_get_conditional_orders with status 'OPEN', and explains the symbol cannot be changed, directing to cancel-and-create for that. It also specifies the follow-up step (toss_submit_prepared_order). However, it doesn't explicitly say when to prefer this over toss_prepare_order_modify or other alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the destructiveHint annotation by clarifying that 'Nothing reaches the market from this call' and that it 'only validates the request and returns a preview plus a confirmation token.' It also discloses the token's single-use and 60-second expiry, providing essential safety and workflow context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with each sentence contributing useful information, but it contains slight redundancy ('Nothing reaches the market' and 'only validates the request' overlap). It is still concise enough for a workflow-critical tool, so it earns a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a prepare-and-submit workflow, the description fully covers the tool's role: it explains what happens (preview only), what doesn't happen (no market impact), how to get the required ID, and the token's expiration and single-use nature. This is complete despite lacking an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter conditionalOrderId with a clear description. The description reinforces the source (toss_get_conditional_orders) but does not add meaningful new semantic information beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact action: 'Previews the removal of an EXISTING conditional order' with the specific verb 'Previews' and resource 'conditional order'. It also distinguishes itself from the sibling tool toss_prepare_order_cancel, which is for already-triggered legs, so the purpose is unambiguous 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: it warns that affected live orders should use toss_prepare_order_cancel instead, instructs to find the ID via toss_get_conditional_orders, and directs the user to submit the token via toss_submit_prepared_order after approval. This clearly explains when and how to use the tool.
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?
The description adds valuable behavioral context beyond the readOnlyHint annotation: it discloses that shares reserved by open sell orders or still settling are excluded, and that the result can be lower than holdings. This is meaningful and non-obvious information that affects how the result should be interpreted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three concise sentences, each serving a distinct purpose: what the tool does, why the value might differ from holdings, and when to use it. There is no irrelevant or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with strong annotations, this description is complete. It covers the purpose, the key behavioral nuance, the return value (how many shares), and the recommended usage context, making it sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the symbol parameter with a clear format and examples, so schema coverage is 100%. The description does not add extra parameter meaning beyond what the schema already provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the number of shares that can be sold right now for a given symbol, using a specific verb and resource. It also differentiates from toss_get_holdings by explaining the quantity can be lower due to reserved or settling shares.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to check this tool before sizing a SELL order, giving a concrete use case. It also names toss_get_holdings as an alternative and explains the difference, helping the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jeric1223/tossinvest-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server