Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses that calculations are objective, based on standard financial formulas, and that no buy/sell recommendation is given. It does not cover potential errors or data assumptions, but the core behavioral limits are transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single substantive paragraph with no filler. The first sentence efficiently lists the output metrics, and the second adds an important caveat. It is longer than some descriptions, but the length is justified by the tool's complexity and the need to set expectations about no buy/sell conclusions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description lists all key output metrics and explains the tool's objective nature. It connects to the sibling list tool via the parameter example. It lacks details on calculation formulas or data freshness, but for the described purpose it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides a clear description for cwSymbol with an example and source ('lấy từ list_covered_warrants'), covering 100% of the parameter. The tool description does not add additional meaning about the parameter beyond context already present in the schema, so it meets the baseline but does not exceed it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes one specific covered warrant in detail, listing the exact metrics it computes (current price, breakeven, premium, moneyness, leverage, liquidity). It is easily distinguished from sibling tools like get_ohlc or list_covered_warrants, as it focuses on warrant-specific financial calculations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides strong context for when to use the tool: when a user needs detailed objective metrics for a specific covered warrant. It explicitly notes that the tool does not conclude whether to buy, setting expectations about its scope. However, it does not explicitly reference alternatives or state when not to use it compared with sibling tools, so it misses the top tier.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It transparently discloses that the tool returns only objective structural/geometric information and does not generate trade recommendations. It also specifies the scope (one Vietnamese stock) and mentions dynamic conditions like 'còn active' and 'gần nhất', giving a clear behavioral picture. Missing are aspects like rate limits or permissions, but for a read-only analysis tool these are minor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of two sentences. The first sentence front-loads the purpose with a clear list of outputs, and the second sentence adds essential limitation context. Every phrase contributes value, with no redundant language.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must explain what the tool returns. It does this by listing the core SMC elements (swing points, trend labels, BOS/CHoCH, active FVG, liquidity sweep), which is sufficient for a model to understand the output. It also addresses how the results should be interpreted (as objective data, not signals). It could be more detailed about the exact structure or type of the returned data, but the list covers the essentials.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage, with descriptions for all three parameters (symbol, resolution, count). The tool description does not add additional meaning about parameters beyond what the schema already provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's purpose: 'Phân tích cấu trúc Smart Money Concepts' for a Vietnamese stock, listing specific outputs like swing high/low, trend (HH/HL or LH/LL), BOS/CHoCH, active FVG, and nearest liquidity sweep. This distinguishes it from sibling tools such as detect_macd_divergence or compute_bar_metrics, which focus on other technical aspects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states what the tool does NOT do: it does not compute bullish/bearish bias or suggest entry/SL/TP, clarifying when not to rely on it for those decisions. It frames the output as objective structural data for Claude's own reasoning, implying when to use it, but it does not explicitly mention alternative tools for other use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden and clearly discloses the key behavioral trait that the tool does not assign signal labels and only returns numeric data. It also mentions it follows threshold descriptions in the skill, adding context about how the data relates to methodologies. It does not mention rate limits or side effects, but for a compute-only tool these are less critical.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading the core function with a specific metric list, then a valuable clarification about non-labeling. It is concise with no filler, and each sentence serves a distinct purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's modest complexity, the description is complete: it lists the outputs (metric names and trend %), explains its role in VSA/Wyckoff analysis, and clarifies its non-labeling behavior. It does not describe the return format or exact trend % computation, but the absence of an output schema makes this a minor gap, and the reference to the skill fills some context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters (symbol, resolution, count) are fully described in the schema with types, defaults, ranges, and purpose (e.g., count warm-up requirement). The description adds context about the computed metrics but does not enrich parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool computes raw per-candle metrics (volume_ratio, spread_ratio, close_position, body_ratio) plus trend %, with a specific verb 'Tính' (calculate). It explicitly distinguishes itself from signal-detection siblings by stating it does NOT auto-label signals, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: it is the objective foundation for identifying VSA/Wyckoff events, and it explicitly says conclusions are left to Claude based on the methodology skill. This implies when to use it (raw data needed) versus signal-labeling tools, though it does not explicitly name alternatives or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It discloses that the tool is a port of a personal alert engine backtested on real VNDIRECT data, and that it returns current status, newly generated signals at the latest candle, and signal history. However, it does not discuss limitations, potential false positives, data sensitivity (e.g., needing enough candles), or any side effects. This is moderate transparency but lacks important behavioral caveats for a detection tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, information-dense sentence that covers purpose, origin, and return values with reasonable efficiency. It is not overly long, but the multiple clauses make it slightly less scannable. A short list or second sentence would improve structure, but it is still appropriately compact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must explain what the tool returns. It does mention three types of return data (current status, new signal at latest candle, signal history) but does not describe the structure or format of these outputs (e.g., boolean, object, or array). For a specialized analysis tool, this is a notable gap. The description also omits any details about the 'lobe-based' algorithm, leaving the agent to infer the input–output behavior. It is adequate for a high-level understanding but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters (symbol, resolution, count) are fully documented in the schema. The tool description itself adds no additional parameter meaning beyond restating the purpose; for example, the note about 'count' needing to be large is in the schema, not the description. Therefore, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool detects MACD divergence (lobe-based) and reversal confirmation status for a Vietnamese stock, which is a specific verb+resource+scope. It is distinct from all sibling tools, none of which mention MACD or divergence detection. The mention of 'alert engine' and 'backtested' reinforces its specialized purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides usage context by explaining the return values are meant for deciding whether to alert immediately ('dùng để quyết định có cần cảnh báo ngay không'). It also implies appropriate use through the resolution guidance in the schema ('1D cho tín hiệu swing, 1H/4H cho tín hiệu ngắn hạn hơn'), though this is in the parameter schema, not the tool description. It does not explicitly state when not to use this tool or name alternatives, but no sibling is a direct alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, this description fully carries the behavioral transparency burden and does so exceptionally well. It explicitly states the null return condition (fewer than 30 candles), and explains that when no tight range exists it still returns the nearest candidate with qualifies:false, including a warning not to misread that flag as true. This directly prevents a common misinterpretation and discloses edge-case behavior comprehensively.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with an action-focused opening, a context sentence about Wyckoff usage, and a detailed edge-case explanation. Each section serves a purpose, though the Wyckoff sentence is somewhat long and could be tightened. Overall, it is well-organized and not verbose for the amount of critical behavioral information it conveys.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even without an output schema, the description outlines the key return fields (upper/lower band, length, flatness), the qualifies flag, and the null behavior. It also connects the tool to a concrete workflow with compute_bar_metrics. It stops short of specifying the exact JSON response shape, but for tool selection and invocation it provides sufficient operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides complete descriptions for all three parameters (symbol, resolution, count), including default, min, and max values. The description adds no significant parameter-level detail beyond referencing the 30-candle minimum, which is already present in the schema. Given the high schema coverage, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with the specific verb 'Tìm' (find) and a clearly defined resource: the nearest sideways price range (trading range) of a Vietnamese stock, including upper/lower boundaries, length, and flatness. It differentiates itself from sibling tools by explicitly positioning the result as objective structural data for Wyckoff phase identification and referencing compute_bar_metrics as a complementary tool for event-level analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear contextual guidance: it is intended for identifying Wyckoff Accumulation phases and should be combined with compute_bar_metrics for SC/AR/ST/Spring/SOS/LPS detection. It does not enumerate when not to use it or alternative sibling tools, but the primary use case is explicit and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full transparency burden. It discloses that each indicator is the latest value from VNDIRECT, acknowledges that some indicators may be missing (e.g., dividendYield for non-dividend stocks), and mentions an 'error' field that explains failures. This is meaningful behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The entire description consists of two concise sentences in Vietnamese: the first states the tool's purpose and data source, the second addresses data availability and error reporting. Every clause adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool without an output schema, the description explains the data source, the list of indicators, the behavior when data is missing, and the existence of an 'error' field. It does not detail the exact return structure (e.g., JSON keys) but covers the essential information an agent needs. This makes it largely complete, though a formal output schema would eliminate ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully documents the single 'symbol' parameter with examples (HPG, VNM, FPT), so the description does not need to add parameter details. The description adds no additional semantics beyond the schema, warranting the baseline score for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'Lấy' (get) with a specific resource: fundamental indicators (P/E, P/B, EPS, ROE, ROA, dividend yield) for a Vietnamese stock from VNDIRECT. This clearly distinguishes it from sibling technical analysis tools like get_ohlc or detect_macd_divergence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for retrieving fundamental data, in contrast to the technical indicators provided by sibling tools. However, it does not explicitly state when to choose this over alternatives or mention exclusions. The context of the sibling list makes the differentiation clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full transparency burden and credibly discloses the VNDIRECT source and the 4H aggregation from 1H candles. This goes beyond a simple 'get data' statement, though it omits return format and 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the action and resource, and each clause adds distinct information. It is appropriately sized for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple data retrieval tool without an output schema, the description gives sufficient context: it identifies OHLCV as the data type, names the source, and explains the 4H anomaly. The absence of explicit return structure is mitigated by the well-known OHLCV format and comprehensive parameter schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides full parameter descriptions, so baseline is 3. The description adds meaningful context by explaining that the 4H resolution is synthesized from 1H, which is not evident from the schema alone, and provides example symbols.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: fetching historical OHLCV data for a Vietnamese stock from VNDIRECT, with specific timeframes. It distinguishes itself from sibling tools by specifying the data type and source, making it unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool by defining its data scope (historical OHLCV) and available timeframes, but it does not explicitly mention alternatives or exclusion criteria. The note about 4H synthesis adds contextual guidance for that resolution.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description takes on the full burden of behavioral disclosure. It clearly states that only static data is returned (no market price), which is a key behavioral trait. It does not mention pagination or potential errors, but for a simple listing tool this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action and data fields, followed by a useful clarification about static data and the intended pre-filter usage. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a simple listing operation with two parameters and no output schema. The description lists the returned fields, notes the lack of market price, and connects to the sibling analysis tool, providing enough context for an agent to select and invoke it. Minor omission: does not mention the default limit/sorting in the main text, but that is captured in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides full descriptions for both underlyingSymbol and limit, including the sorting behavior for limit. The description adds no extra parameter-level detail, but since schema coverage is 100%, a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists covered warrants for a specific underlying stock at VNDIRECT, enumerates the returned fields (CW code, issuer, exercise price, conversion ratio, maturity date, days remaining), and explicitly distinguishes it from the sibling tool analyze_covered_warrant by positioning it as a pre-filtering step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use this for preliminary filtering before calling analyze_covered_warrant for detailed analysis, naming the alternative tool. This gives clear guidance on when to use this tool and how it fits in a workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description takes full responsibility for behavioral disclosure. It warns that relative paths resolve to the MCP server's cwd, not the bot's, and gives a Telegram-specific requirement. It doesn't mention file overwriting or permissions, but for a chart renderer 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first states the core functionality and output, the second adds practical path guidance. Both sentences carry necessary information with no redundancy, making it concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter chart tool with no output schema, the description covers purpose, output format (PNG), file path constraints, and a specific use case (Telegram). Combined with complete schema descriptions, an agent has all needed information to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline is 3. The description references SMA, MACD, and volume panels, but the schema already explains all parameters in detail, so the description adds no unique semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it draws a technical candlestick chart for one Vietnamese stock, listing components (SMA, MACD, volume) and output as PNG. This distinguishes it from sibling tools focused on data retrieval or analysis, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides context on when to use the tool (when a PNG chart is needed) and a specific condition for sending via Telegram. However, it doesn't explicitly compare with alternatives or state exclusions, so it falls short of the highest bar.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.