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

With no annotations at all, the description carries the whole burden, and it does disclose useful behavior: empty product_name/shop_name are backfilled by the crawler, site/currency are parsed from the URL, and base_price empty means 'skip'. It does not say whether monitoring starts immediately, what happens on a duplicate URL (idempotency), or what happens when URL parsing fails — significant gaps for a create/mutation tool.

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

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

Purpose is front-loaded in one sentence, then user phrasings, then a compact bullet list of parameters — a sensible order. The example utterances are slightly verbose for a definition body, but they earn their place by anchoring invocation intent.

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?

Return values are covered by the output schema, and parameter defaults/fallbacks are well explained. Still missing for an un-annotated create tool are duplicate handling, immediate-vs-deferred crawl behavior, and failure modes on an unparseable URL, which an agent would need before confidently invoking it.

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 0%, so the description must compensate, and it largely does: it walks through all eight parameters, marks product_url as required, lists supported sites (my/th/vn/sg/id/ph/br), and explains the meaning of each optional field. It only omits finer details such as the currency unit for base_price and any valid range for check_interval/alert_threshold.

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 first sentence gives a specific verb plus resource ('添加一个新的商品到监控列表'), and it is clearly distinct from read-side siblings like get_monitor_list or get_monitor_overview. An agent can tell this is the creation path for a new monitored product without inspecting any schema.

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 '用户可能的问法' examples give concrete trigger conditions and make clear this is the entry point whenever a user supplies a Shopee URL to track. There is no explicit exclusion or routing statement (e.g. what to do if the product is already monitored, or whether to use search_my_products first), so it stops short of a full when/when-not guide.

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 and does meaningful work: it discloses the state transition to adopted, the default-fill behavior (actual_price 留空则采用建议的 target_price), and an edge case where certain decision types have no target price so actual_price may remain empty. It does not state preconditions (must the decision be pending?) or whether adoption is reversible, which keeps it short of a 5.

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

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

The action and state outcome are front-loaded in the first sentence, then parameter notes, then an edge-case caveat. The example utterances are slightly verbose but directly aid routing, and no sentence is redundant filler.

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?

An output schema exists, so return values need no explanation, and for a two-parameter mutation the description covers the key semantics and one important edge case. Missing are precondition/validation behavior (e.g., what happens if the decision was already adopted or rejected), which an agent would want before calling a state-changing tool.

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 0%, so the description must compensate, and it does: decision_id is identified as the decision ID, and actual_price is defined both as the executed price and as optional with a documented fallback to the suggestion's target_price. The only gap is the absence of format/range hints for the price value.

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?

States a specific verb+resource (采纳一条决策建议) and the resulting state change (状态变为 adopted), which goes beyond the tool name. It does not explicitly contrast itself with sibling review_decision or reject_decision, so an agent must infer the boundary from the verb alone.

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?

Three example user utterances ('这条建议我采纳了', '我实际执行价是 195…', '把那条降价建议标记为已采纳') give concrete trigger contexts, which is genuinely useful. However there is no explicit when-not guidance or named alternative (e.g., 'to reject instead, use reject_decision'), leaving the sibling boundary implied.

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 and does disclose real behavior: the created record defaults to status 'suggested', expires for review after 14 days, and feeds statistics/review loops. It also documents the return payload (decision_id, review_at). It does not mention permissions, whether duplicate decisions are allowed, or failure modes.

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?

Front-loaded with the core behavior, then parameter semantics, then return values — a logical reading order. The user-phrasing bullet block is mildly redundant but does add intent-matching value; the rest is tight.

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 5-parameter mutation tool with no annotations, it covers purpose, all parameters, side effects on status/expiry, and return fields (an output schema exists so return details need not be exhaustive). Missing only edge-case guidance such as valid monitor_id preconditions or duplicate handling.

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 coverage is 0% and no enum is declared, so the description does essential work: it enumerates the five valid action values, states target_price is expected for follow_price/raise_price, and explains that context_json accepts an object and will be serialized. That compensates fully for the empty schema descriptions.

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 states a specific verb and resource (record a follow-sell decision, status=suggested, 14-day review), plus the downstream lifecycle. It also names adopt_decision and reject_decision as the follow-up actions, so an agent can separate creation from adoption/rejection without opening other schemas.

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 example user utterances ("记一下我的决定：跟着降到 199") map natural-language intents to this tool, which is unusually actionable guidance. It also describes the workflow continuation via adopt_decision/reject_decision, but never states when NOT to use it (e.g., versus review_decision or when a decision already exists).

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 must carry the behavioral load. It implies a safe read-only listing operation and discloses meaningful limits (default 10, max 50 for limit). However, it does not discuss permissions, ordering, pagination beyond limit, or failure behavior, so gaps remain for a tool with zero 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.

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

The description is front-loaded with the core purpose, followed by compact usage examples and then the parameter list. The example questions add routing value rather than just filling space. It could be tightened, but everything included supports selection or invocation.

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?

Output schema exists, so return-value documentation is not required. For a zero-required-parameter read tool, the description covers purpose, usage triggers, and all three parameters. Minor omissions such as ordering or what fields an alert contains are acceptable given the output 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?

Schema description coverage is 0%, so the description has to compensate. It explains all three parameters: unread_only filters unread alerts (default false), site filters by site, and limit caps the number of results (default 10, maximum 50). The maximum of 50 and the purpose of site are facts that the bare schema does not convey, though there is no format guidance for site.

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 states a specific verb and resource: it fetches the list of price alerts, covering all drop alerts the system has pushed, along with scoping for unread-only and site filters. This clearly separates it from sibling tools such as mark_alert_read or get_price_summary, though it never names a sibling explicitly or with an explicit comparison.

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 tells an agent what to use this tool for by listing the kinds of user questions this tool answers, such as "any new drop alerts" or "how many unread alerts". That is strong context for routing. There is no explicit when-not-to-use guidance, and no alternatives are named, so it falls short of a 5.

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

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: 查看 marks it as a read-only listing, 无参数 confirms it has no inputs, and the return field set (algo_id、名称、是否启用、params) is disclosed up front. It omits whether the list is global vs. user-scoped and any auth/rate-limit context, which keeps it from a 5.

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

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

The core statement is front-loaded in the first sentence, followed by routing examples and the return contract — a sensible order. The three-line utterance list is somewhat padded and could be trimmed, but each block does contribute to disambiguating intent.

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 zero-parameter list tool with an output schema, purpose plus return-field summary is essentially complete. The minor gap is that it doesn't say how the returned algorithm IDs/params are meant to be consumed downstream (e.g. fed into run_smart_follow_analysis), leaving the workflow linkage implicit.

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 tool takes zero parameters, which sets the baseline at 4, and the description explicitly confirms this with 无参数 so an agent never hunts for inputs. The mentioned return fields add nothing for parameters but are harmless.

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?

States a specific verb+resource (查看智能跟卖算法清单) with an explicit scope (ALG-01~12) and even names the fields inspected (启用状态与参数). The resource is unambiguous and clearly distinct from siblings such as get_monitor_list or get_price_summary, so an agent can route without opening the schema.

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 three sample user utterances ("现在启用了哪些跟卖算法", "ALG-08 的参数是多少", "系统用哪些规则给我出建议") give concrete triggers for when to call it. It does not, however, name any alternative tool or state when NOT to use this one (e.g. versus get_smart_follow_stats), so it stops short of explicit exclusion guidance.

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. The word '查看' implies a read-only operation, and the parenthetical clarifies the return shape. However, it does not disclose permissions, pagination behavior, or whether the result is scoped to the caller's account, which leaves meaningful behavioral gaps for a tool with zero 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.

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

The core purpose is front-loaded in the first sentence, followed by example phrasings and a parameter note. The example questions are useful for intent matching but add some length; overall the structure is efficient and each section serves a 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?

With an output schema present, the description needn't explain return values, and it correctly focuses on purpose and the single optional parameter. The main remaining gap is the lack of explicit sibling differentiation from map_competitors, but for a one-parameter read tool this is largely 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 0%, so the description must compensate. It does so by explaining that self_owned_monitor_id restricts results to a specific self-owned product and that leaving it blank returns all mappings, which adds real meaning beyond the bare integer/null 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 states a specific verb and resource: it returns the mapping from a self-owned monitor ID to a list of competitor monitor IDs. This is clear enough for an agent to understand the tool's output shape. However, it does not explicitly distinguish itself from the sibling tool map_competitors, which likely creates or edits these mappings, so the agent must infer the read-only nature from the word '查看'.

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 three example user phrasings that clearly indicate when this tool applies, which is strong intent-matching guidance. It does not, however, name an alternative tool or state when not to use it, such as when the user wants to create a mapping instead of view one.

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 behavioral burden. It discloses the important scoping constraint (data covers only the current user's monitored products) and that it is a direct, no-arg read of a health report, but it doesn't state permissions, rate limits, or freshness semantics. An output schema exists, so return-shape details are reasonably omitted.

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 purpose is front-loaded in the first sentence, followed by example intents and a scope note. The example list is slightly padded but each line serves routing value, so it stays efficient overall.

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?

No parameters, an output schema, and no annotations make this a simple tool, and the description covers purpose, scope, and invocation. An agent has enough to call it correctly; only minor behavioral detail (e.g. what 'stale' means) is missing.

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 zero parameters and 100% schema coverage, the baseline of 4 applies. The description correctly reinforces that it takes no parameters, adding no contradictory or missing parameter guidance.

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 states a specific verb and resource ('检查后台采集引擎的运行状态') and enumerates what the report contains: crawl counts, per-site status, and stale-monitor detection. It doesn't explicitly name a sibling it is not (e.g. get_monitor_overview or get_smart_follow_stats), so an agent must infer differentiation from content rather than explicit disambiguation.

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?

Four example user phrasings map clear intents to this tool, which is strong routing guidance for an intent-matched agent. It also states that no parameters are needed. It lacks explicit when-not-to-use or named alternatives, keeping it at 4 rather than 5.

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 present, so the description carries the full load. It discloses that the result is an array of monitor items with fields including product name, shop, site, baseline price, current price, change magnitude, and status, which is useful. It says nothing about permissions, pagination, list size limits, or whether 'active' is the implicit default filter.

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 one-line purpose is front-loaded, followed by a compact bullet list of user phrasings and a single return-shape sentence. No filler sentences.

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?

An output schema exists, so the return-value sentence is somewhat redundant but harmless. For a zero-required-param read tool the main gaps are undocumented parameter semantics and the lack of any routing guidance against the many read siblings, leaving the definition only minimally sufficient.

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 0% and the description never names the two parameters. The example questions ('SG 站...' and '暂停中的监控...') hint at site and status filtering, but there is no explanation of accepted values, that status defaults to 'active', or that site is nullable.

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 states a specific verb+resource: '获取用户正在监控的商品列表' (retrieve the list of products the user is monitoring). It is clearly distinguishable from mutation siblings like add_monitor and update_monitor_status, though it doesn't differentiate itself from get_monitor_overview or get_price_summary.

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?

Four example user phrasings ('我在盯哪些商品', 'SG 站有几个商品在监控', '我的监控列表', '暂停中的监控有几个') give concrete triggers for when this tool applies. However, no exclusions or alternative-tool routing are given, so an agent can't tell when get_monitor_overview would be preferred.

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 load, but it is a zero-parameter aggregate read and the output schema already defines the return shape, so the burden is light. It does state that no parameters are needed and that the result is a dashboard summary, yet it says nothing about access scope, whether the data is cached or real-time, or any rate limits.

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?

Purpose and content list are front-loaded in the first sentence; the query examples and the no-parameters note are short and each serves a routing or clarity function. No filler sentences.

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 zero-parameter read tool with an output schema that already documents the returned fields, the description is sufficient: it names the resource, lists the summary categories, and clarifies invocation. The only real gap is the absence of guidance on how this differs from sibling summary tools.

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 tool takes zero parameters, which is the baseline-4 case. The closing '无需参数' merely confirms what the empty schema already shows and adds no further semantics.

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?

States a specific verb and resource ('获取所有监控的总览大盘数据') and enumerates the contents (active monitor count, today's collection/alerts, per-site distribution). This distinguishes it from the sibling get_monitor_list, which lists individual monitors rather than aggregating them, though the description never says so explicitly.

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 three example user phrasings ('给我一个监控总览', '我的所有商品监控情况怎样', '大盘数据看看') give an agent concrete routing signals for when this tool applies. However, no alternative is named and no case is excluded, so the agent must infer that get_monitor_list or get_price_summary cover narrower questions.

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, and it does disclose the days default of 7 and the 90-day cap, which is useful behavioral context. It omits whether the monitor_id must belong to the caller, whether results are paginated, and what happens when no data exists in the window.

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 core purpose is front-loaded in the first sentence, followed by parameter constraints. The example-query bullet list is longer than strictly necessary but earns its place by giving the agent phrasing matches for retrieval.

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?

An output schema exists, so return-value explanation is correctly omitted, and the parameter constraints are covered. The only meaningful gap is not telling the agent how to obtain a valid monitor_id or how this differs from get_price_summary.

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 0%, so the description has to compensate, and it does: monitor_id is marked required, and days is documented with both its default (7) and hard maximum (90), which the bare schema does not say. It does not explain where a monitor_id comes from (e.g. get_monitor_list), leaving that link implicit.

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 states a concrete verb and resource: fetching a time series of price data for a given product, with the stated downstream uses (trend charting, price-change analysis). This implicitly separates it from get_price_summary, but it never names that sibling, so an agent must infer the boundary itself.

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 four example user phrasings ("近 7 天的价格走势", "价格变化记录", "画个价格折线图", "竞品今天是什么价格") give concrete trigger conditions for when to reach for this tool. However, it never states when NOT to use it or points to get_price_summary as the alternative for aggregate/snapshot queries.

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 must carry the safety profile itself; the 'get/摘要' framing implies a read-only operation and it discloses the important behavioral rule that omitting monitor_id aggregates ALL active monitors. It does not state permissions, rate limits, or whether inactive monitors are excluded, which is meaningful for an aggregation 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 purpose statement is front-loaded, followed by example queries and then fallback/default rules — a sensible order for an agent reading top-down. The example list is slightly padded but each line maps to a distinct invocation pattern, so nothing is truly wasted.

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?

An output schema exists, so return values need not be described, yet the description still names the summary fields, and all three optional parameters are covered behaviorally. The remaining shortfall is the absence of annotations, leaving the safety/permission profile implicit for an aggregation query.

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 0%, so the description must compensate, and it does: it explains that monitor_id is optional and scopes to a single product vs all active monitors, that site filters by site, and that days defaults to 3. The only gap is that site's accepted format (e.g. 'SG') is shown only by example in a sample query rather than specified.

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 first sentence gives a specific verb and resource ('获取...价格摘要') and enumerates the returned metrics (current price, baseline, max/min/avg, trend direction), which clearly separates it from a raw history tool. It never names the closest sibling (get_price_history) or explains how a 'summary' differs from 'history' or 'overview', so differentiation is implied rather than stated.

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 three concrete user-phrasing examples ('竞品最近价格怎么样', 'SG 站上盯的几个商品近 2 天价格怎样', '有没有降价的竞品'), which is strong positive routing guidance. It also defines the no-monitor_id fallback behavior. It stops short of stating when to prefer get_price_history or get_monitor_overview instead, so no exclusions are given.

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 and does disclose real behavioral traits: results are limited to the most recent analysis (not a history), and target price is null/'—' for actions other than follow_price/raise_price. It does not cover the empty state (no analysis run yet) or any permission/scope constraints, which is the remaining gap.

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?

Purpose is front-loaded in the first sentence, followed by clearly delimited blocks for query phrasings, the optional parameter, and action-value semantics. Every block is labeled and the value glossary prevents misinterpretation of the returned action field.

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 optional-parameter read tool with an output schema, the description covers what is returned, the meaning of the action enum, and the null semantics of target price — the agent can call and interpret it correctly. Only the no-data case and the provenance of monitor_id remain unspecified.

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 0% — monitor_id has no description or enum in the schema — but the description compensates with '只看指定监控项的结果', clarifying it acts as a filter rather than a selector. It omits where to obtain a valid monitor_id (presumably get_monitor_list), which would have made the parameter fully actionable.

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 opening line gives a specific verb and resource ('查看最近一次智能跟卖分析的结果') plus the exact payload (suggested action, target price, reason, competitor snapshot per self-owned product). It implicitly distinguishes itself from run_smart_follow_analysis by scoping to the most recent existing result, but it never names that sibling or get_smart_follow_stats, so the differentiation is left to inference.

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 '用户可能的问法' block gives concrete routing triggers ('最近一次跟卖分析结果是什么', '系统建议我跟着降价吗') that map natural-language intents to this tool. There are no explicit exclusions or named alternatives telling the agent when to prefer run_smart_follow_analysis or get_smart_follow_stats instead.

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 burden and does add real behavioral context: the window is fixed at 30 days (not caller-configurable) and the review-effective rate only counts decisions that have an effective/ineffective conclusion. It never explicitly states this is a read-only, side-effect-free query, which keeps it below 5.

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?

Front-loads the resource and metric list, then adds example phrasings and the one meaningful caveat; nothing is padded. The example-question block is slightly verbose but earns its place as routing signal.

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?

An output schema exists, so return-shape explanation is unnecessary, and a zero-parameter read tool has little additional risk to disclose. The fixed 30-day window and metric definition are covered, leaving little an agent would still need to know before calling.

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 has zero parameters, so the baseline is 4 by rule. The description's 'no parameters' note is consistent with the empty schema but adds nothing beyond 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?

States a specific verb and resource (view smart-follow decision statistics) plus the exact metric set (total suggestions, adoption rate, rejection rate, review-effective rate, per-action breakdown) and the 30-day scope. This clearly separates it from analysis/results siblings like run_smart_follow_analysis and get_smart_follow_results, though no sibling is named explicitly.

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 example user questions ("what's my adoption rate", "how did smart-follow perform last month", "which actions get the most suggestions") give concrete routing signals for when to select this tool. There is no explicit when-not-to-use or named alternative, 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.

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

With no annotations, the description carries the burden and does well: it discloses ordering (descending by creation time), that status filtering and truncation happen MCP-side rather than in the API, and that the header reports the total count. It omits any note on permissions or failure behavior, but the read-only listing nature is clear.

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?

Front-loaded with purpose, then example queries, then parameters, then a behavioral note. Well-organized and generally tight, though the example-query block adds length that could be trimmed for a simple list tool.

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?

An output schema exists so return structure needn't be explained, and the description still notes the header total count. For a 3-param filtered list tool the coverage is essentially complete; only explicit permission/edge-case behavior is absent.

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 0% and parameters carry no descriptions or enums, so the description must compensate. It does: monitor_id (limit to a monitor), status with the enum values suggested/adopted/rejected, and limit with default 20 are all explained with meaning beyond the bare 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?

States a specific verb+resource: viewing historical follow-sell decision records, with scope (filterable by monitor and status). The 'list' semantics are clearly distinct from the create_decision/review_decision/adopt_decision/reject_decision siblings that mutate state.

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 example user questions ('what decisions did I make recently', 'which suggestions are unhandled', 'iPhone decision history') convey when to reach for this tool. Usage context is concrete, though no explicit exclusions or named alternatives are given.

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 and does so well: it discloses overwrite semantics (replaces all existing mappings), the empty-list clear operation, the ownership precondition, and atomic rejection with no partial writes. These are exactly the traits an agent needs before calling a destructive mutation.

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 overwrite warning is front-loaded and the param list is compact. The example-phrasings block is somewhat verbose but earns its place by aiding intent matching; overall structure is clean with no filler.

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 2-parameter mutation with no annotations, the definition covers purpose, parameters, destructive scope, and failure mode. An output schema exists, so return values need not be described; nothing necessary is missing.

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 coverage is 0%, and the description fully compensates by defining both parameters, including the non-obvious empty-list-equals-clear semantics that the schema's array type does not convey. This adds real meaning beyond the input 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?

States a specific verb and resource: setting the competitor mapping for one self-owned product. An agent knows exactly what mutation occurs. It does not name the read counterpart (get_competitor_mapping) to differentiate, which keeps it from a 5.

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 'user phrasings' block gives concrete triggers (attach competitors, map against IDs 101/102/103, clear all mappings), which maps natural-language intent to this tool. There is no explicit when-not or alternative routing, so it falls short of a 5.

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

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

No annotations exist, so the description carries the full burden, yet it does not say whether marking read is reversible, whether read alerts disappear from get_alerts or merely change status, whether the call is idempotent, or what happens if the alert_id is invalid. '保持预警列表干净' hints at list hygiene but never explains the mechanism, which leaves real ambiguity for a mutation tool.

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

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

The opening sentence is well front-loaded and earns its place, but the example list is padded, and the second example actively misleads rather than clarifying. Trimming or correcting the examples would make the whole definition tighter and more accurate.

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 output schema means return values need not be explained, but for a mutation tool with no annotations and an undocumented parameter, the description should still cover provenance of alert_id, idempotency, and the effect on subsequent get_alerts results. None of that is present, and the bulk-read example adds a misleading expectation rather than filling the gap.

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 0%, so the description must compensate for the single alert_id parameter. It only restates the field name as '预警记录 ID' and adds no meaning beyond the schema title, and says nothing about where to obtain a valid ID (e.g., from get_alerts) or what form it takes.

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?

States a specific verb and resource ('将某条预警标记为已读') and adds a purpose clause ('保持预警列表干净'), which distinguishes it from the read-only siblings like get_alerts. The scope is slightly clouded by the example '所有预警都标为已读', which implies bulk behavior the single-alert_id schema cannot deliver.

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 user-phrasing examples imply when to invoke the tool, which is useful context not present in structured fields. However, there are no explicit exclusions or alternatives, and the bulk-reading example contradicts the single-record scope, leaving the agent to infer which requests this tool can actually satisfy.

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. It discloses a meaningful downstream behavior—only self-owned products are picked up by the smart-follow batch processing—but says nothing about idempotency, permissions, or what happens to the existing flag on repeated calls.

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

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

The core behavior and downstream effect are front-loaded, followed by example utterances that aid matching, then the parameter note. The examples add length but each reinforces a distinct invocation scenario rather than restating the same point.

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?

An output schema exists, so return values need not be explained. The description covers the action, the toggle semantics, and the business consequence, leaving only permission/idempotency details unstated for a simple mutation.

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 coverage is 0%, so the description must compensate; it does so for the non-obvious boolean by stating that is_self_owned defaults to true and that false means unmarking. monitor_id is only named, but its semantics are self-evident from the tool purpose.

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?

States a specific verb and resource (mark/unmark a monitored item as self-owned) plus the functional consequence: only self-owned items enter the smart-follow batch. This clearly separates it from sibling tools like update_monitor_status or add_monitor.

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?

Provides concrete user phrasings that indicate when to invoke it ("this product is mine, mark it self-owned", "cancel the self-owned flag"), which gives a clear usage context. It does not, however, name an alternative tool or an explicit when-not-to-use condition.

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 burden and does disclose real behavioral traits: the backend does not restrict state transitions (a rejected decision can later be adopted again) and the MCP layer performs no pre-validation. What it omits is the failure mode — what happens if decision_id does not exist — so it's strong but not exhaustive.

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?

Front-loaded with the action and resulting state, then example phrasing, then caveats — a sensible order. The example-question list is a little verbose, but each line maps to a distinct user phrasing and earns its place for intent matching.

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 one-parameter mutation with no annotations, the description covers outcome state, the re-adoption/state-flow caveat, and the no-pre-validation warning; the output schema covers return values. Missing only error behavior and ID provenance, which are minor at this complexity.

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 0%, so the description must compensate; it does say decision_id is required and that the caller should confirm the ID before operating. It does not explain where the ID comes from (e.g. list_decisions) or what type/format it takes, so a meaningful gap remains.

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?

States a specific verb and resource ('拒绝一条决策建议') and the resulting state ('状态变为 rejected'), so the effect is unambiguous. It does not name adopt_decision or review_decision as the contrasting siblings, so it stops short of full differentiation.

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 example user utterances ('这条建议不采纳', '拒绝那个提价建议') give concrete intent-matching context for when this tool applies, and the ID-verification note sets a precondition. There is no explicit when-not guidance, e.g. 'to approve instead, use adopt_decision', so routing between the decision siblings still needs inference.

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 and does disclose a non-obvious consequence: passing only free text without review_result means the review will not be counted in statistics. That is real behavioral value beyond the name. It still omits whether a repeated review overwrites a prior one, or what errors occur for an invalid decision_id.

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 purpose is front-loaded, followed by example queries and a compact parameter block. The closing 说明 partially restates the parameter section (text vs. enum), which is mild but justified redundancy given the statistical side effect it warns about.

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?

An output schema exists so return values need not be explained, and the parameters are well covered. However, for a mutation tool with zero annotations, it never states prerequisites—must the decision already be adopted/executed, and is re-review allowed—leaving an agent unable to predict failure modes.

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 coverage is 0%, and the description compensates fully: it explains decision_id, marks review_outcome as required free text with a concrete example ('降价后 7 天销量 +12%'), and enumerates the three review_result values effective/ineffective/inconclusive that appear nowhere in the schema. It also clarifies the division of labor between the two review fields.

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 states a concrete verb and resource: review a decision and record its actual post-execution effects, which clearly differs from create/adopt/reject in the sibling list. It does not explicitly name those siblings as alternatives, so differentiation is inferred rather than stated.

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?

Three example user phrasings plus the temporal cue '执行后' make clear when this tool applies (after a decision has been carried out and results are known). It stops short of exclusions—it never says what to do if the decision was never adopted or is still pending.

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 burden and does well: it discloses synchronous execution with a maximum 180-second wait and that a timeout does not mean the batch stopped — it may keep running in the background, so results should be re-checked later. It does not say whether the run creates or mutates decision records, which is the main remaining behavioral gap.

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?

Purpose is front-loaded in the first sentence, followed by example utterances, the optional parameter, and timeout behavior. The sample question list is slightly padded but earns its place by improving routing accuracy; overall it is well structured with no real filler.

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?

An output schema exists, so return-value detail is not required, and the description covers the operation's scope, timing, timeout semantics and next step. The one omission is whether the run has side effects on stored decisions, which matters for a batch analysis tool.

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 coverage is 0%, so the description must compensate, and it does: monitor_id is explained as restricting analysis to one self-owned monitor item, with omission meaning all self-owned, enabled products. That is exactly the semantics an agent needs and goes beyond the bare integer type in 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?

States a specific verb and resource: triggers a smart follow-sell batch analysis, names the algorithm set (ALG-01~12 with decision chains), and says it runs synchronously and returns result status. The closing pointer to get_smart_follow_results makes clear this tool runs the analysis while that sibling only reads results.

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?

Gives three concrete user phrasings that should route here and an explicit handoff: after the run completes, use get_smart_follow_results to see per-product suggested actions, target prices and reasons. That covers when to use this tool and what to do next, leaving little to inference.

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 at all, the description must carry the behavioral load. It usefully discloses that matching covers both product name and store name, and the search framing implies a non-mutating read. It does not state result ordering, limits, or how partial matches behave, so the disclosure is only partial.

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 tool purpose is front-loaded in the first line, followed by example phrasings that earn their space by helping intent matching. The trailing '需要提供 keyword' line is slightly redundant with the required-field schema but is minor.

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 one-parameter read/search tool with an output schema present, the definition covers purpose, matching scope, and trigger phrasings — enough to call it correctly. Result cardinality and ranking behavior are the only notable omissions, and the output schema partly covers those.

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 single parameter has 0% schema description coverage, so the description must compensate — and it does, explaining that 'keyword' is the search term and that it matches against product name or store name. No format, length, or encoding constraints are given, which keeps it short of a 5.

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 states a specific verb ('按关键词搜索') and a precisely scoped resource ('用户的监控列表中'的商品), and clarifies the match fields (product name or shop name). It implicitly distinguishes itself from the sibling get_monitor_list (which enumerates rather than keyword-filters), but never names that alternative.

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 list of example user phrasings ('搜一下我监控里有没有 AirPods', 'Samsung 相关的商品有几个在监控') gives concrete context for when this tool is the right pick over enumerating the monitor list. It stops short of explicit when-not-to-use guidance or naming an alternative tool.

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 discloses the two target states but not the effects of the transition (does pausing suppress alerts/crawls?), idempotency for an already-paused monitor, or permission requirements. Reversibility is implied by the pause/resume pairing, but the operational consequences are unstated.

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?

Core purpose is front-loaded in a single sentence, followed by usage examples and the required parameters. The example list is somewhat verbose but earns its place by covering multiple user phrasings; no other padding is present.

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 two-parameter mutation with an output schema, the description covers purpose, the exact state values, and required inputs. The remaining gap is behavioral: with no annotations, error conditions and side effects on alerting are left for the agent to discover.

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 0% and the status field has no enum in the schema, so the description's explicit mapping of status to "paused" (暂停) / "active" (恢复) is essential information an agent could not otherwise infer. monitor_id is only restated as "监控项 ID", adding little beyond its name.

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 first sentence states a specific pair of verbs (pause/resume) acting on a specific resource (monitor item), which is immediately distinguishable from siblings like add_monitor or get_monitor_list. An agent can classify the operation without opening the schema.

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?

Three example user utterances map colloquial phrasings ("先暂停", "停掉", "恢复") onto this tool, which gives concrete when-to-use context. It stops short of naming exclusions or alternatives (e.g., that it does not create or delete monitors), so it is clear but not fully routing.

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