HOTLIKESHOP MCP

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

With no annotations provided, the description carries the full behavioral burden. It explicitly discloses read-only behavior, no api_key requirement, stock filtering, return-field limitations, and sort order. This is strong coverage for a simple read-only list tool.

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

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

The core English explanation is front-loaded and information-dense, with clear usage signposts. The repeated Vietnamese sentence adds bilingual accessibility but duplicates the English wording, so it is slightly redundant.

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?

Despite no output schema, the description names the exact return fields. Parameter docs are complete in the schema, usage alternatives are explicit, and no missing prerequisite or context is needed for an agent to invoke this 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?

Schema coverage is 100%, so the baseline is 3; the description adds value by explaining that category_id comes from list_categories and by framing keyword/category as optional scoping mechanisms. It does not merely repeat schema text.

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 a specific verb ('List'), identifies the exact resource ('best-selling in-stock public products'), states the ordering ('most sold first'), and constrains the response to 'public fields only (price VND + units sold)'. This clearly differentiates it from sibling listing and search tools.

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 explicit 'WHEN TO USE' guidance ('popular / hot / most bought') and a 'PREFER INSTEAD' section that names four sibling tools with their selecting contexts: latest_products, search_products, recommend_products, and list_category_products. No inference is required.

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 full disclosure responsibility. It fully discloses irreversibility, spending real balance, delivering the product, and returning order_code plus content. It also warns against speculative calls and notes the token's freshness requirement, all of which are critical for an agent to safely invoke this high-stakes action.

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 well-structured with clear labels (STEP 2, IRREVERSIBLE, PREREQUISITE, WHEN TO USE, AFTERWARDS) and every sentence serves a purpose. However, the Vietnamese sentence at the end essentially repeats the same information as the English, which is slightly redundant for an AI agent, though not distracting.

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 an irreversible, balance-spending action with no output schema, the description is remarkably complete: it explains the return value (order_code + content), prerequisites, when to call, and what to do afterwards. An agent would have everything needed to invoke this tool correctly and safely.

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 covers both parameters with detailed descriptions (api_key matching quote_order; confirm_token validity and single-use). The description reinforces these prerequisites but does not add new semantic meaning beyond the schema. Since schema coverage is 100%, 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 specific verb ('place the order') and resource ('confirm_token from quote_order'), and explicitly positions it as 'STEP 2 of buying', distinguishing it from sibling tools like quote_order and check_order_status. The irreversible nature and balance spending are immediately highlighted, leaving no ambiguity about what this tool does.

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?

Usage is explicitly gated: 'PREREQUISITE: a fresh confirm_token', 'WHEN TO USE: only AFTER the user has explicitly approved the exact total', and 'Do NOT call speculatively or to re-price.' It also names the follow-up tools (check_order_status, get_mail_code, submit_complaint) and their conditions, giving the agent a complete decision framework.

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?

There are no annotations, so the description carries the full behavioral burden. It discloses read-only/free/no-api_key behavior, the max-batch limit, the skipped status for unverifiable IG/FB items, and why a user-supplied proxy is needed. It does not enumerate every possible per-item status or edge case, but the main runtime caveats are clearly communicated.

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 English text is well-structured and front-loaded with the core purpose, followed by practical caveats and routing guidance. The bilingual Vietnamese section duplicates the English content, which is not strictly necessary for the agent and prevents a perfect score, but it remains compact and targeted.

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 3 parameters, 100% schema coverage, no annotations, and no output schema, the description is complete enough for correct invocation. It covers input types, supported platforms, batch size, proxy behavior, free access, expected result shape, and alternative tools — everything an agent needs to select and call this 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?

Schema coverage is 100%, giving a baseline of 3. The description adds value beyond the schema by clarifying that Facebook UIDs are numeric, restating the 20-item limit, and linking the proxy parameter to unverifiable IG/FB items. It doesn't add much about the platform parameter, but it doesn't need to since the schema already documents the default.

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 a concrete action and resource: bulk live/dead checking for many accounts, listing supported platforms, the 20-item cap, and output shape. It also names the sibling tools it should be preferred over, so an agent can differentiate it from check_live_facebook and deep_inspect without opening their 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?

Contains explicit 'WHEN TO USE' guidance (list of 2-20 accounts, or any non-Facebook platform) and 'PREFER INSTEAD' guidance (check_live_facebook for a single Facebook UID, deep_inspect for one detailed profile). This leaves no ambiguity about which tool to choose.

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 burden. It discloses read-only behavior, no API key requirement, server-side execution, datacenter IP blocking by Facebook, the special 'needs_proxy' status, and the remedy of passing your own proxy. This is substantial behavioral context.

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

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

The description is information-dense and well front-loaded, with clear labels and routing guidance. The bilingual repetition adds length, but it serves a multilingual audience and does not obscure the core guidance.

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 low-complexity tool with no output schema, the description covers purpose, endpoint, authentication constraints, failure mode, proxy usage, and alternatives. The only minor gap is that it does not explicitly list the exact return values for 'live' vs 'dead', though this is strongly implied by the tool's purpose.

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 100%, so the schema already documents uid and proxy. The description adds meaning beyond the schema: it explains that uid must be numeric, that Facebook blocks datacenter IPs, that proxy is user-supplied and request-scoped, and why the proxy parameter matters. This exceeds the baseline for full 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 opens with a specific action and scope: 'Check whether ONE Facebook UID (numeric) is live or dead via the public profile-picture endpoint'. It clearly distinguishes this single-UID Facebook checker from sibling tools like check_health_bulk and deep_inspect.

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?

Explicit 'WHEN TO USE' section states this is for a single Facebook UID. It also names alternatives: use check_health_bulk for many accounts or other platforms, and deep_inspect for detailed profile data. This gives an agent clear routing criteria.

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 burden and excels. It discloses read-only default, no spending, the refresh parameter's async and safe nature (never charges, never touches completed/refunded orders), and suggests polling after 5-10s. It also mentions the delivered content (account credentials). This is exceptional transparency.

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 thorough but well-structured with headings (PREREQUISITE, WHEN TO USE, PREFER INSTEAD) and a Vietnamese translation. The main purpose is front-loaded, and every sentence contributes value. It is longer than typical but justified by the tool's optional refresh behavior and alternatives.

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 tool with 3 parameters, no output schema, and no annotations, the description covers all necessary context: purpose, prerequisites, usage scenarios, alternatives, safety guarantees, and polling guidance. An agent can invoke this correctly without any external documentation.

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 100%, so baseline is 3. The description adds meaning beyond the schema: it clarifies that api_key is required, order_code comes from buy_product or list_orders, and refresh is only for stuck orders and is optional. This adds context that the schema alone does not provide.

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 checks the status and delivered content of a single order by order_code, distinguishing it from list_orders (all orders) and other sibling tools. The verb 'Check' and resource are specific, and the scope 'ONE of your orders' prevents ambiguity.

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?

Explicit 'WHEN TO USE' and 'PREFER INSTEAD' sections provide direct guidance: when to use the tool, when to set refresh=true, and when to use alternatives like list_orders, get_mail_code, and submit_complaint. This fully routes an agent to the correct tool for the situation.

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 present, the description carries the full burden, and it does well by disclosing server-side verification from real data, idempotency ('a second call will not double-credit'), and that rewards credit the SHOPPING balance and are not withdrawable. It does not describe the success/failure response format, but the core behavioral contract is clearly documented.

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 main action is front-loaded, and labeled sections like PREREQUISITE, WHEN TO USE, and PREFER INSTEAD make the guidance scannable. Minor redundancy exists: 'Requires api_key' repeats the schema requirement, and the Vietnamese sentence largely duplicates the English content without adding new information.

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 mutation-style claim tool with no annotations and no output schema, this description is unusually complete: it covers the prerequisite state, idempotency, reward destination, non-withdrawability, and correct sibling routing. An agent can confidently execute the intended sequence: use list_quests to find a claimable quest_key, then call claim_quest.

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 100%, so the baseline is 3; the description adds meaningful context by specifying that quest_key must be complete-but-unclaimed and can be sourced from list_quests or gamefi_status. It also reinforces the idempotent behavior around the quest_key parameter, going beyond mere field labels.

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 precise verb and resource: 'Claim the reward for ONE completed quest', and differentiates itself from sibling reward tools by emphasizing the single-claim scope and 'one claim per quest per period'. It explicitly names what it is not for by routing to list_quests and daily_checkin/spin_wheel, so an agent can distinguish it without opening 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?

Provides explicit 'WHEN TO USE' and 'PREREQUISITE' sections, requiring a quest_key that is complete-but-unclaimed from list_quests or gamefi_status. It also tells the agent when to prefer alternatives, such as list_quests to discover claimable quests and daily_checkin/spin_wheel for those specific reward types.

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 clearly discloses read-only behavior, no api_key required, public fields only, and price in VND. It does not detail failure modes (e.g., invalid ids) or exact output structure, but the core behavioral traits are well covered.

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 compact and front-loaded with the core action and fields, followed by usage guidance and alternatives. The Vietnamese repetition at the end is somewhat redundant with the English text, but it does not significantly harm clarity or length.

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 read-only comparison tool with one parameter and no output schema, the description covers the purpose, prerequisites, usage context, alternatives, and data scope. It lacks explicit return-format details, but the summary output is described and the tool is simple enough that this is a minor 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 coverage is 100%, so the schema already documents the 'ids' parameter. The description adds value by clarifying the accepted range (2–5), giving an example format, and noting that a comma-separated string is also accepted. This goes beyond the schema's basic type/description.

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 ('Compare'), a resource ('2–5 public products'), and the exact fields compared (price, stock, min/max, sold, category), plus the summary output (cheapest / most stock / best seller). It clearly distinguishes itself from siblings like get_product and similar_products.

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 the prerequisite (already have 2-5 product ids), when to use it (help the user pick between specific candidates), and names preferred alternatives (get_product, similar_products, search_products / list_category_products) with their conditions. This is exemplary routing 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?

There are no annotations, so the description carries the full behavioral load. It is transparent about the key behavioral business rule: the server returns a live Pay ID and a unique USDT amount with cents, and the agent must relay them verbatim without inventing. It also discloses the prerequisite and the required follow-up call, which ensures the agent knows the actual operational flow.

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 well-structured and front-loaded, using explicit labels for prerequisite, when-to-use, afterwards, and preference. However, it includes a complete Vietnamese translation of the initial English prompt, which is redundant for an English-centric AI agent and lengthens the text without adding new guidance. This duplication prevents a perfect conciseness score.

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 compensate and it does: it tells exactly what the server returns (Pay ID+QR and unique USDT amount with cents) and instructs to relay them verbatim. It also explains required prerequisites, the follow-up verify call, and the alternative when on-chain transfers are needed. The context is fully sufficient for a correct call.

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%; the only parameters, api_key and amount_usd, already have clear descriptions in the input schema. The tool description does not add new parameter-specific meaning beyond what the schema provides (e.g., the schema already says amount_usd is a whole-number USD amount and the system assigns a unique cents suffix). Therefore, the description does not improve on the structured parameter info.

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 says exactly what the tool does: 'Create a Binance Pay deposit order to top up your balance.' It names a specific verb and resource. It further distinguishes itself from its sibling create_usdt_deposit by explicitly saying to prefer that one for on-chain USDT transfers.

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 explicit usage guidance with labeled sections: PREREQUISITE (api_key and Binance Pay enabled), WHEN TO USE (user pays inside the official Binance app), AFTERWARDS (call verify_binance_deposit with merchant_trade_no), and PREFER INSTEAD (use create_usdt_deposit for on-chain). This is a model of when-to-use and when-not-to-use guidance.

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

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

Since no annotations are provided, the description carries the burden and meets it by disclosing critical behaviors: the server generates the receiving address, the amount includes cents, the address must be relayed verbatim, and the response flow (verify_usdt_deposit later). It does not specify the exact response format, but this is partially covered by the dense operational detail. A 4 is justified because the description proactively surfaces unusual behaviors (unique cents, generated address) that are not obvious from 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 description is exceptionally well-structured: the first three lines cover core purpose and critical warning, followed by a clear 'PREREQUISITE', 'WHEN TO USE', 'AFTERWARDS', and 'PREFER INSTEAD' structure. Every sentence carries actionable information, and the Vietnamese line is a translation for usability, not fluff. It's dense but not bloated.

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 deposit tool with 3 simple parametersched and no output schema, the description covers all essential context: prerequisites, supported networks, critical behavior (address generation), post-call actions (verify), and alternatives. No schema or annotations are needed to make a correct call. It is comprehensive for the given 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?

The schema already has 100% parameter coverage, so the baseline is 3. The description goes beyond by clarifying that 'network' defaults to trc20 (schema also says, but description reinforces), and adds the subtle point that amount_usd is whole-number only and the system appends cents. It doesn't add new parameter-specific semantics beyond the schema, but the reinforcement of the 'unique cents' behavior for amount_usd adds value, warranting a slight bump.

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 purpose is explicitly stated with a specific verb ('Create') and resource ('USDT deposit order'), and it clearly distinguishes itself from the sibling 'create_binance_deposit' by mentioning the alternative for Binance app users. The description also details supported networks and key requirements, making its purpose unmistakable.

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

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

The description provides explicit when-to-use ('the user wants to deposit on-chain USDT'), BEFORE/AFTERWARDS flow with prerequisite (call topup_guide first), and an alternative ('Prefer instead: create_binance_deposit'). It also warns against inventing wallet addresses, giving clear usage boundaries.

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

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

No annotations exist, so the description must carry all behavioral info. It discloses idempotency, reward formula, streak bonuses, the extra lucky-wheel spin, crediting to a non-withdrawable shopping balance, and API key requirement. Exceptionally transparent for an unannotated 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?

Information is front-loaded and logically structured. The Vietnamese translation at the end is redundant with the opening, so it's not perfectly concise, but the WHEN TO USE/PREFER INSTEAD sections make it highly scannable.

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 one-parameter tool, the description fully covers purpose, preconditions, effects, idempotency, reward type, and related alternatives. No output schema exists, but the description tells the agent what to expect.

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?

Only one parameter, api_key, with 100% schema description coverage. The description merely repeats that it requires api_key without adding extra semantics, so it meets but does not exceed the baseline.

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 the specific operation (once-a-day check-in), the outcome (collect reward), and distinguishes it from related tools like claim_quest, gamefi_status, and spin_wheel. There is no ambiguity about what the tool does.

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?

Explicit WHEN TO USE section tells the agent to invoke it when the user wants to claim today's free check-in, and PREFER INSTEAD points to gamefi_status, spin_wheel, and claim_quest as alternatives. This is exactly the kind of decision guidance needed.

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: it states read-only, public data only, free/no api_key, best-effort behavior, and the 'needs_proxy' failure mode with proxy remedy. It does not mention timeout or malformed-input outcomes, hence not a perfect 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 information is front-loaded and dense, with only one unnecessary piece: the final Vietnamese sentence recaps the English content. Otherwise every sentence either defines scope, states behavior, or routes the agent to a sibling.

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 description is complete enough for selecting and invoking the tool: it covers platforms, output data categories, proxy behavior, and alternatives. With no output schema, an explicit JSON response shape would strengthen it, but it already tells the agent what data to expect per platform.

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 the baseline is 3. The description adds no new parameter semantics beyond the schema—the schema already documents proxy syntax, full-URL handles, and the platform enum—though it does emphasize 'pass your own proxy' for IG/FB.

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 a specific verb and resource: 'Deep profile lookup for ONE social account' and enumerates the exact data per platform. It also names sibling tools and what they are not, so there is no ambiguity about scope.

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 explicit routing: 'WHEN TO USE: you want rich detail about one profile' and 'PREFER INSTEAD: check_health_bulk ... check_live_facebook ...', making the choice among siblings fully explicit.

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 burden and does so well: it explicitly states the operation is read-only, that rewards credit the SHOPPING balance and are not withdrawable, and that an api_key is required. This is clear behavioral disclosure for a query-only tool.

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

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

The description is well-organized with a clear purpose statement, usage directive, and behavioral note. The Vietnamese repetition at the end adds length but may serve a bilingual audience; overall it remains compact and front-loaded.

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 simple read-only nature, the description fully equips an agent: what it returns, when to call it, what to do after, and the key behavioral caveat (SHOPPING balance, not withdrawable). No output schema exists, but the described content is sufficient for correct invocation.

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 covers both parameters and their meanings (language and API key), and the description adds that api_key is required)Skip. However, the description repeats 'Requires api_key' already in schema and does not add semantic value beyond the 100% schema coverage, so the baseline 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 states a specific verb and resource: 'One-shot overview of all FREE balance rewards' the account can grab right now, and enumerates the exact areas (daily check-in, lucky wheel, quest board). It clearly distinguishes this aggregate status tool from the individual action siblings like daily_checkin, spin_wheel, and list_quests.

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?

Contains an explicit 'WHEN TO USE' directive: call this first whenever the user asks about rewards/free balance, then follow up with the specific collection tools. This gives unmissable routing and sequencing guidance and names the sibling tools directly.

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 burden. It discloses that the code is computed in-memory only, never stored or logged, requires no API key, is free, and is not sent anywhere. These are the key behavioral facts an agent needs when deciding to call this 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 English portion is well-structured and front-loaded with purpose, then behavior, then usage guidance. Some redundancy exists because the same content is repeated in Vietnamese, but that bilingual repetition can serve a broader user base without harming clarity.

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, no-output-schema tool, this description is complete. It explains the input, output, privacy behavior, alternative tool, and necessary conditions, so an agent has everything needed to call it 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?

The input schema already documents the secret parameter 100%, including that spaces are allowed. The description adds only 'requires a valid Base32 secret,' which is useful but not a major semantic addition beyond the structured 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 starts with a specific verb and resource: 'Generate the current 2FA/TOTP code (6 digits) from a Base32 secret key (Google Authenticator style).' It clearly identifies the output format and input type, and the 'PREFER INSTEAD' clause distinguishes it from get_mail_code.

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?

WHEN TO USE gives a concrete condition: the user has an authenticator secret key and needs the live TOTP code now. PREFER INSTEAD explicitly names get_mail_code for email OTP codes, so an agent can route between the two tools without ambiguity.

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 burden of behavioral disclosure. It does note the operation is read-only and describes the required credentials, which adds some transparency. However, it does not mention failure modes, rate limits, or the format of the returned OTP/code, so the transparency is limited.

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 English portion is well-structured: it states the purpose, prerequisites, when-to-use, and alternatives in compact sentences. The score is not 5 because the Vietnamese translation is largely redundant, doubling the description length for the same content.

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 simple and its two parameters are fully covered by the schema. The description covers prerequisites, use case, and alternatives, which is strong for a read-only lookup tool. However, it does not discuss the output or how OTP retrieval behaves (e.g., live polling vs cached), leaving some ambiguity for the agent.

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 the schema already documents both required parameters. The description reinforces that order_code must be for a mail-bundled account, which adds a small nuance beyond the schema, but it does not compensate for low schema coverage or add deep value. Baseline 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 verb 'get' and the specific resource ('latest email OTP / verification code' for a mail-bundled account), and explicitly distinguishes the supported providers. It also helps differentiate from sibling tools like get_2fa and check_order_status.

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 a clear PREREQUISITE (api_key + order_code with inbox), a WHEN TO USE statement, and explicit PREFER INSTEAD alternatives (get_2fa for TOTP, check_order_status for delivered credentials). This fully covers when and when not to use the tool.

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

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

No annotations are provided, so the description carries the burden. It explicitly states 'Read-only, spends nothing' which is a key behavioral trait. It also notes the requirement for a valid api_key. It does not mention error handling or rate limits, but for a simple read operation this is adequate. It discloses the return fields (balance, level, discount) which adds context.

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, then provides usage guidance and alternatives. It includes a redundant Vietnamese translation, but it does not add much bulk. Overall it is well-structured and every 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?

For a single-parameter tool with no output schema, the description covers what it returns (balance, level, discount), when to use it, and what alternatives exist. An agent has everything needed to invoke it correctly. The Vietnamese translation also aids non-English users.

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 100% and the api_key parameter is fully described in the schema, including its source ('Trang cá nhân → API'). The description only repeats that it requires the api_key, adding no new semantics beyond the schema. Baseline 3 is appropriate given the high 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 clearly states the verb and resource: 'Get your account balance, level and discount' and explicitly differentiates from siblings by naming wallet_history, topup_guide, and quote_order as alternatives. This makes it unambiguous which tool to pick for balance queries.

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 explicit 'WHEN TO USE' conditions (user asks 'how much do I have' or needs to confirm funds before quote_order/buy_product) and 'PREFER INSTEAD' guidance for alternative tools, covering both when to use and when not to use.

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 burden of behavioral disclosure. It states 'Read-only, no api_key required' and clarifies that a known product id, not a name, is required. It also describes the returned data fields, though error behavior and edge cases are not covered.

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 English content is well-organized and front-loaded, with clear WHEN TO USE / PREFER INSTEAD sections. However, the final Vietnamese sentence repeats the same purpose, read-only status, and auth info already covered in English, adding redundancy without new 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?

With no output schema, the description compensates by listing the return fields (name, price VND, stock, category, long description, url). It also supplies prerequisites, usage context, alternatives, and next-step routing to quote_order, making the tool safely callable without further research.

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 100% for the single id parameter, but the description adds meaning beyond 'Product id.' by specifying that the id is numeric, must be a known product id rather than a name, and is the output of specific sibling search tools.

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 names a specific verb ('Get'), a single resource ('ONE product'), the identifier type ('numeric id'), and enumerates the returned fields (name, price VND, stock, category, long description, url). It also contrasts with siblings like compare_products and similar_products, so the tool's scope is 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 an explicit 'WHEN TO USE' section naming the preceding tools (search_products / list_category_products / best_sellers) and the exact user-intent condition. The 'PREFER INSTEAD' section routes to compare_products and similar_products, and it explicitly excludes buying by directing to quote_order.

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 burden. It explicitly discloses that the tool is read-only)SkipTransformers, no api_key required, and that it lists which other tools need an api_key. This is useful and honest. It does not describe the output format, but for an onboarding guide this is a minor 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?

The description is well structured with explicit WHEN TO USE and PREFER INSTEAD sections.text is compact, front-loads the purpose, and the bilingual content is intentional and self-documenting.

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 read-only guide with one optional language parameterabweeks, the description covers when to use it, what it covers, auth/key requirements, read-only behavior, and alternatives. No output schema exists but the function is simple enough that the description is 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?

The schema has one optional lang parameter with full coverage (100%). The description adds that 'en' is the default and gives a bilingual explanation, which reinforces the semantic without needing extra detail.

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 names a specific verb+resource ('Onboarding guide... how to start buying'), lays out the exact workflow (create account -> get api_key -> top up -> search & buy), and distinguishes itself from siblings by naming what it is not (topup_guide, quote_order, buy_product, search_products). An agent can tell exactly what this tool is for.

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?

Explicit 'WHEN TO USE' states it is the very first call for a new/international user or whenever someone asks 'how does this work'. It also gives 'PREFER INSTEAD' alternatives for top-up details, purchasing, and browsing, leaving no ambiguity about 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?

No annotations are provided, so the description carries the burden. It discloses read-only behavior, no api_key required, in-stock filtering, public-fields-only output, and price in VND. It does not mention pagination or what happens when no products match, but the core behavioral traits are clearly stated.

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 compact and front-loaded with the core behavior, followed by routing guidance and optional scoping. The bilingual Vietnamese repetition adds some redundancy, but it is not excessive and may serve multilingual users.

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 read-only list tool with no output schema and no annotations, the description covers the essential context: what is returned, ordering, filtering, and authentication. It lacks explicit pagination details and a note about empty results, but the tool is simple enough that these are minor gaps.

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 the schema already documents all three parameters. The description adds context by mentioning category_id comes from list_categories and that keyword filters by product name, but this is marginal 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 states a specific verb ('List'), a resource ('newest in-stock public products'), and a clear ordering ('recently added first'). It also distinguishes itself from siblings by naming the exact use case ('new arrivals / just added') and explicitly listing which sibling to prefer for other intents.

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 explicit WHEN TO USE and PREFER INSTEAD guidance, naming four sibling tools and the conditions that select them. It also notes optional scoping via category_id or keyword, giving an agent clear decision rules.

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?

Since no annotations are present, the description carries the full burden here. It clearly states 'Read-only', 'takes no parameters', 'no api_key required', and clarifies that it returns only category metadata with counts, not individual products. It does not discuss edge cases like empty responses or error formatting, but it covers the core behavioral risk well.

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 and uses scannable 'WHEN TO USE' and 'PREFER INSTEAD' headings. It is slightly longer than necessary because the Vietnamese sentence repeats the existing English content, and 'This only lists categories' partially restates earlier information.

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 very simple zero-parameter read-only category listing tool with no output schema, the description is complete enough. It states the output fields (id, name, in-stock count), highlights which sibling tools require the returned category_id, and gives the correct starting context for an agent.

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?

There are zero parameters, so the schema already captures the full parameter surface. The description adds a small amount of value by making the no-parameters/no-api-key situation explicit, though it does not need to explain individual parameter behavior.

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 the exact resource and action: list every public category with id, name, and in-stock product count. It also distinguishes itself from other tools by explicitly saying it does not return individual products, making this useful for agent 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?

The description contains explicit 'WHEN TO USE' and 'PREFER INSTEAD' guidance. It tells the agent to call this tool first to discover category taxonomy and gather category_id values for the listed sibling tools, and gives alternatives such as search_products when a keyword is already known.

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 disclosure burden. It clearly states 'Read-only, no api_key required', limits results to 'in-stock public products', and describes the return fields (id, name, price, stock). This is strong behavioral transparency for a simple list operation.

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 most important information is front-loaded, and the use of labels like PREREQUISITE, WHEN TO USE, and PREFER INSTEAD makes it scannable. It loses one point for the redundant Vietnamese sentence that repeats the opening English sentence almost verbatim.

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 low-complexity read-only list operation with only two parameters)Skip, the description gives everything needed to select and invoke the tool correctly: scope, prerequisites, output fields, read-only behavior, authentication requirements, and routing to alternatives. No output schema is needed to fill gaps.

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 covers both parameters with 100% description coveragecars, so the baseline is 3. The description adds meaning by explaining where category_id comes from ('get category_id from list_categories first') and by emphasizing the single-category scope, which is not explicit 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?

The description uses a specific verb-resource pair: 'List in-stock public products inside ONE category by category_id' and explicitly names the fields returned. The phrase 'inside ONE category by category_id' distinguishes it from sibling tools like search_products, list_categories, and best_sellers.

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 explicit when-to-use ('browse everything in a chosen category'), a prerequisite ('get category_id from list_categories first'), and clearly named alternatives (search_products, best_sellers, latest_products). It also states what it is NOT for ('buying; for purchases, use quote_order'). This makes tool selection unambiguous.

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 that the operation is read-only ('Read-only, spends nothing'), requires an api_key, and is paginated. It doesn't disclose details like rate limits or error behavior, but the key behavioral traits (safety, cost, pagination) are covered. The 'spends nothing' note is particularly valuable for an agent deciding whether to call this 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 English portion is dense and front-loaded with the core purpose, followed by usage routing. The Vietnamese repetition at the end is redundant for an English-speaking agent and adds length without new information, which prevents a 5. However, the structure is otherwise efficient and every English sentence earns its place.

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 paginated list tool with no output schema, the description covers the essential context: what it returns, that it's read-only, that it costs nothing, and how to follow up. It doesn't describe the response format or pagination details beyond 'paginated', but the output schema absence is partially mitigated by the field list. The main gap is not describing what happens with invalid api_key, but overall this is quite complete for its 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 100%, so the schema already documents all three parameters (page, limit, api_key). The description adds the context that api_key is required and that pagination exists, but doesn't add meaning beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('List'), a resource ('your recent orders'), and the exact fields returned (order_code, product, quantity, total paid, status, date). It also explicitly distinguishes itself from wallet_history, which is a sibling that could be confused with it. This is a clear, specific purpose statement.

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 explicit WHEN TO USE guidance ('the user wants their purchase history or you need to find an order_code'), explicit AFTERWARDS routing to check_order_status and get_mail_code, and explicit PREFER INSTEAD guidance to use wallet_history for money movements. This is exemplary usage guidance with both positive and negative selection criteria.

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 disclosure burden. It explicitly states 'Read-only, spends nothing' and 'Requires api_key', disclosing the safety profile and a prerequisite — meaningful behavioral context. It doesn't cover error conditions or the empty-boards case, a minor gap for a simple read tool, so a 4 rather than 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?

Core purpose is front-loaded, with usage routing after. However, the trailing Vietnamese sentence ('Danh sách nhiệm vụ ngày/tuần kèm tiến độ + phần thưởng') redundantly restates the English content, adding length without value for an English-consuming agent — keeping it from a 5.

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 no output schema, the description bears the burden of explaining return content, which it does thoroughly (enumerating quest key, title, reward, progress, complete, claimed). Combined with the api_key prerequisite and sibling routing, nothing an agent needs to call it correctly is missing for a 2-param list 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 100%, so the schema already documents both params (lang: language for titles, api_key: shop account API key). The description adds only 'Requires api_key' reinforcement and a Vietnamese phrase implying language handling, which is at the baseline for full schema coverage — no substantial new meaning over 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 states a specific verb and resource ('List the daily & weekly quest board') with detailed itemization of what each entry returns (quest key, title, reward, current/target progress, completion, claimed status). This clearly distinguishes it from gamefi_status (combined summary) and claim_quest (a mutation action on a single quest).

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?

Explicit WHEN TO USE ('the user wants to see quests or you need a quest_key'), AFTERWARDS routing ('call claim_quest on any quest that is complete but not yet claimed'), and PREFER INSTEAD alternative ('gamefi_status for a combined rewards summary'). This is textbook usage guidance that removes all ambiguity about when to pick this tool versus its siblings.

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 itself discloses key behavior: the operation SPENDS NOTHING, returns a single-use confirm_token with ~5 minute validity, and is a prerequisite for the purchase step. This meaningfully covers side-effect transparency beyond what the schema shows.

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 well-structured and front-loaded with the purpose, returns, and safety guarantee. The bilingual Vietnamese repetition adds length without new information, but the core message remains clear and scannable.

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 quote tool with no output schema, the description fully covers what the caller needs: the business step, the result fields, the no-charge behavior, token expiry, required parameters, and the follow-up action. No critical usage context 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?

Input schema coverage is 100% and already documents api_key, product_id, and quantity with defaults. The description adds only a restatement that api_key and product_id are required, so it adds limited new 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?

Explicitly identifies this as 'STEP 1 of buying' and names the operation as retrieving a price quote before purchase. It lists the returned artifacts (unit price, discount, total, balance, stock, confirm_token) and clearly distinguishes itself from buy_product and other related tools.

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 an explicit WHEN TO USE rule: always call this first, show the total to the user, get approval, then call buy_product. It also names alternatives for other needs: get_my_balance for balance-only checks and check_order_status for existing orders.

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?

Despite no annotations, the description discloses read-only behavior, no api_key requirement, public-fields-only output, in-stock filtering, and cheapest-first ordering. It doesn't describe response structure or edge cases, but it carries most of the behavioral burden for a safe read-only call.

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?

English is front-loaded and compact, with usage guidance clearly labeled. The Vietnamese repetition adds some token redundancy but doesn't obscure meaning.

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 optional-parameter read tool with many siblings, the description provides purpose, behavior, sort order, auth requirements, scope source, and alternatives. No output schema exists, so exact return fields are not specified, but the description names public fields and price VND.

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 already covers all four parameters at 100%, so baseline is 3. The description adds value by clarifying that budget and keyword/category can be combined ('and/or') and by pointing to list_categories as the source of category_id.

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?

Description opens with a specific verb and resource: recommend in-stock public products, and specifies selection criteria (budget, keyword/category), ordering (cheapest first), and combo suggestion. It also contrasts with sibling tools, so an agent can distinguish it from search_products, best_sellers, latest_products, and list_category_products.

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?

Contains an explicit 'WHEN TO USE' section (budget or vague need) and a 'PREFER INSTEAD' routing table naming four sibling tools and their exact selection conditions. This fully resolves tool-selection ambiguity.

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 that the operation is read-only, requires no api_key, and returns a specific set of fields. It also states the tool is not for buying, which is a behavioral boundary. It doesn't mention pagination or error behavior, but for a simple read-only search tool, the disclosed traits are sufficient to set expectations.

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 compact and front-loaded with the core purpose, followed by return fields, read-only note, and usage routing. The bilingual Vietnamese line at the end is redundant with the English text, which costs a small amount of conciseness, but the overall structure is efficient and scannable.

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 2-parameter read-only search tool with no output schema, the description covers the essential context: what it searches, what it returns, when to use it, and what to do next. It doesn't explain pagination or the exact format of the price field, but those are minor gaps given the tool's simplicity and the schema's 100% parameter coverage.

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 the schema already documents both parameters (query and limit). The description adds the context that the query is a keyword in the product name and that the search is against the public catalog, which slightly enriches the schema. However, it doesn't add much beyond the schema's own descriptions, so baseline 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 states a specific verb ('Search'), a specific resource ('the public catalog'), and a specific scope ('by keyword in the product name'). It also lists the return fields (id, name, price, stock, category, url), which makes the tool's purpose unmistakable. It distinguishes itself from siblings by naming what it is not for (browsing, best sellers, latest, full detail).

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 WHEN TO USE: when the user already has a search term or product name. It also names alternatives: list_categories + list_category_products for browsing without a keyword, best_sellers for 'popular', latest_products for 'new', get_product for full detail of one id. It even routes to the next step (pass a found id to quote_order). This is exemplary usage guidance.

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

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

No annotations exist, so the description carries full burden. It discloses read-only, no api_key required, public fields only (price VND + units sold), and explains ordering/fill logic, going well beyond a bare operation statement.

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, but the description is verbose with a redundant Vietnamese repetition of the same content. It could be more concise without losing clarity.

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 no output schema, the description explains return fields (price VND + units sold) and ordering/fill behavior. It also covers prerequisites and usage guidance. Minor gap: no error handling details, but that is acceptable.

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 100% with both id and limit described. The description adds minimal extra meaning beyond confirming id is the base product, so a baseline 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?

States a specific verb (list) and resource (similar in-stock public products) with clear criteria (same category, best-selling first, fills from other categories). It also names alternatives like search_products and recommend_products, distinguishing it from siblings.

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?

Explicitly provides WHEN TO USE (suggest alternatives/cross-sell) and PREFER INSTEAD (search_products, recommend_products, list_category_products), giving agents clear routing 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 must carry the behavioral burden — and it does thoroughly: 'Consumes exactly one spin (NOT free to repeat)', 'earned from check-ins/deposits', 'credits shopping balance (not withdrawable)', 'Requires api_key'. All side effects and preconditions are disclosed in plain language.

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?

Information is front-loaded — the core action and outcome come first, followed by the consumption warning possession. Caps-labeling (PREREQUISITE, WHEN TO USE, PREFER INSTEAD) makes it scannable. Slight redundancy: the closing Vietnamese sentence restates already-covered content (one spin per call), which adds length without new information.

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?

Covers purpose, side effect (consumes a spin), source of spins, destination of winnings, auth requirement, and sibling routing. With no output schema, it could additionally note error/edge-case behavior (e.g., what happens when the user has zero spins), but as-is it gives an agent everything needed to decide and execute the call.

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 100% for the single parameter (api_key is described as 'Your shop account API key.' in the schema). The description only restates 'Requires api_key' without adding format or origin details, so it adds little beyond the schema. Baseline 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 opening clause uses a specific verb and resource ('Spin the lucky wheel once') and states the output ('return the prize won + new balance'). The action is unmistakable and distinct from siblings like daily_checkin or gamefi_status, which appear in the same inventory.

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?

Explicit WHEN TO USE ('user has spins and wants to use one') and PREFER INSTEAD (`daily_checkin` to earn a spin, `gamefi_status` to check spin count) sections name the exact alternatives and the conditions that select them. An agent gets full routing 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?

Although no annotations are provided, the description clearly discloses that the operation is NOT idempotent (one complaint per order), advises confirming with the user before calling, explains the review timeline (3 days) and auto-refund behavior, and notes the requirement for an API key. This goes beyond the schema to cover critical behavioral traits.

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

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

The description is dense but well-structured with a clear lead sentence, then prerequisites, when-to-use, and alternatives. The bilingual repetition is redundant for English-only agents but not harmful; overall it front-loads the most critical constraints (idempotency, confirmation) and remains compact given the complexity.

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 side effects (auto-refund, non-idempotent), the description fully covers prerequisites, timing, follow-up steps, and safety warnings. With no output schema, the description doesn't need to detail return values; the provided behavior and usage guidance are complete for an agent to invoke it correctly.

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

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

The input schema has 100% coverage with detailed parameter descriptions already. The description adds minimal extra parameter meaning but reinforces that order_code must be delivered and faulty, and that reason examples are provided. Since schema coverage is high, the baseline is 3, but the description adds useful constraint context, justifying a 4.

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 explicitly states the tool files a complaint/warranty-refund request for one delivered order, and clearly distinguishes it from related tools like check_order_status by specifying it's for faulty items vs. stuck orders. The verb 'file a complaint' and resource 'warranty-refund request' are specific and 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?

Provides explicit when-to-use conditions (item wrong/dead/login-fails/short quantity), when-not-to-use (if order looks stuck, use check_order_status instead), and names the alternative tool to prefer. Also gives a prerequisite (delivered and genuinely faulty) and a follow-up action (track via check_order_status).

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 burden. It clearly states the tool is read-only ('never moves money', 'Info only'), and explains what happens when api_key is passed (shows balance and shortfall). It could mention rate limits or error behavior, but the core behavioral traits are well disclosed.

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

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

The description is dense but well-organized with clear labels (WHEN TO USE, PREFER INSTEAD) and a bilingual note. It earns its length by providing routing and behavioral context, though the Vietnamese repetition adds some 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 read-only informational tool with no output schema and no annotations, the description covers purpose, usage, alternatives, and parameter effects. It lacks details about the exact response format, but the tool's simple nature and explicit read-only guarantee make it 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?

Schema coverage is 100%, so the schema already documents all three parameters. The description adds context for api_key (shows balance & shortfall) and amount (computes shortfall), which aligns with the schema. It doesn't add much beyond the schema, but the baseline 3 applies because coverage is high.

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 explains how to add funds, lists active deposit methods/networks and min/max, and explicitly says it is info-only and never moves money. It distinguishes itself from deposit creation tools and other siblings.

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?

Explicitly says WHEN TO USE: call this FIRST before create_usdt_deposit or create_binance_deposit, and PREFER INSTEAD alternatives like how_to_start and get_my_balance. This is exemplary routing 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 disclosure burden. It clearly states the side effect (credits your balance), the read behavior (reads matching transfer), and idempotency. Could also mention whether it requires authentication beyond api_key, but the main behavioral traits are well disclosed.

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

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

Well structured with front-loaded purpose, critical behavioral info (idempotent, polling interval), prerequisite, and alternatives. Slight redundancy from the Vietnamese repetition, but it is compact and each English sentence earns its place.

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 annotations and no output schema, yet the description covers the key operational facts: what it does, when to use, the prerequisite ID, idempotency, and polling interval. It does not describe the return payload, but for a poll-like verify operation the core guidance is present.

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 100%, with both parameters described. The description repeats the origin of merchant_trade_no (from create_binance_deposit) which slightly reinforces semantics but adds no new detail beyond schema. Baseline 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 operation: checking/confirming a Binance deposit created by create_binance_deposithol, and credits balance when matched. It distinguishes itself from verify_usdt_deposit by name in the WHEN TO USE guidance, so an agent can tell them apart 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?

Explicitly says when to use it ('after the user has paid via Binance Pay'), mentions polling cadence (~12s), and names the alternative for USDT (verify_usdt_deposit) plus balance inspection afterwards. This is actionable routing 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?

With no annotations, the description fully discloses the operation's key behaviors: scans the blockchain, credits only when a matching transfer is found, is idempotent, and can be polled every ~15s. It makes side effects and retry safety explicit.

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?

Information is front-loaded with prerequisites and usage guidance in labeled sectionsfer to inspect balance afterwards.' The repetition in Vietnamese adds length, but the structure is clear.

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 annotations and no output schema, the description covers what the tool does, prerequisites, side effects, polling behavior, and alternatives. An agent has enough context to invoke it successfully without consulting other 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful usage context: order_code and claim_token come from create_usdt_deposit, and method='hash' + tx_hash enables hash-based verification. This elevates it above schema-only documentation.

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 a specific verb ('Check / confirm') and resource ('a USDT deposit created by create_usdt_deposit'). It clearly distinguishes itself from verify_binance_deposit and relates to sibling create_usdt_deposit.

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?

Explicitly states when to use, prerequisites, polling cadence, and includes a PREFER INSTEAD section naming verify_binance_deposit, get_my_balance, and wallet_history. This is strong selection 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. It discloses that the operation is read-only ('Read-only, spends nothing'), pagination behavior (20/page, newest first), and the response shape (running balance after each entry, totals in/out). It does not mention rate limits or auth failure behavior, but for a read-only ledger tool the disclosed traits are substantial.

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 dense but well-organized: it front-loads the core behavior, then pagination, then read-only safety, then usage routing, then a Vietnamese summary. Every sentence earns its place and the structure makes it easy to scan.

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 paginated read-only list tool with 100% schema coverage and no output schema, the description covers the essential call context: what entries appear, ordering, pagination, safety, and alternatives. It does not describe the exact response fields beyond running balance and totals, but that is a minor gap given the absence of an output schema and the tool's simplicity.

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 the schema already documents both parameters (page, api_key). The description adds the default page size and ordering context ('20/page, newest first') but does not add meaning beyond what the schema provides. Baseline 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 states a specific verb ('Get the balance ledger'), a clear resource (account balance ledger), and enumerates exactly what entries are included (top-ups, spends, refunds) plus the running balance and totals. It also distinguishes itself from siblings like get_my_balance and list_orders, so an agent can tell it apart 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?

Explicitly provides a WHEN TO USE section ('user wants a history of money movements or to audit where funds went') and a PREFER INSTEAD section naming get_my_balance for the current number and list_orders for purchase/order details. This is exactly the kind of routing guidance that helps an agent choose correctly.

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