Server Quality Checklist

Tool Scores

• hoton_buy_premiumA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It transparently states that the tool 'Returns messages[] to sign with @ton/mcp', indicating it builds a signable order rather than executing directly. However, it does not disclose prerequisites such as wallet setup, payToken implications, or post-signing behavior.

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

  Conciseness5/5

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

  The description contains two short sentences and every phrase is useful: the action, the duration options, the recipient scope, and the return shape. It is front-loaded and appropriately sized.

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

  Completeness2/5

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

  This is a moderately complex tool (5 params, nested wallet, no output schema), and the description only sketches the order-building behavior. It lacks details about wallet requirements, payToken semantics, recipient identifier format, and what happens after signing, so an agent would need to rely on sibling tools or schema despite low schema coverage.

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

  Parameters2/5

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

  Schema coverage is only 20% (only referrer has a description), so the description must compensate. It adds 'one user' and '3, 6 or 12 months', but those largely restate the schema's required fields and enums. The payment token, wallet object, and recipient format remain unexplained.

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

  Purpose5/5

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

  The description uses a specific verb 'Build an order to gift Telegram Premium' and states the scope 'to one user', which clearly distinguishes it from sibling hoton_buy_premium_bulk. The title reinforces the single-recipient scope.

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

  Usage Guidelines4/5

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

  The phrase 'to one user' establishes a clear context for single-recipient gifts, and the sibling list includes a bulk variant, making the intended use evident. It does not explicitly name alternatives or exclusions, so a score of 5 is not warranted.

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

• hoton_buy_premium_bulkA
  3.7/5.0
  Behavior4/5

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

  Lacking annotations, the description compensates by disclosing that the tool returns messages[] to sign with @ton/mcp, indicating the order is not executed directly. However, it doesn't cover permission requirements, fee effects, or failure behaviors.

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

  Conciseness5/5

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

  Two concise sentences are front-loaded with the core action and key constraint; no filler. Every sentence earns its place.

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

  Completeness2/5

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

  With five parameters, no annotations, and no output schema, this description is too sparse to fully guide invocation. It lacks details on signing flow, parameter formats, and edge cases.

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

  Parameters2/5

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

  Schema coverage is only 20%, and the description adds minimal parameter meaning. It clarifies that the same duration applies to all recipients and sets the 1–10 user count, but payToken, wallet, and referrer are left unexplained.

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

  Purpose5/5

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

  The description clearly states the tool builds a single order for gifting the same Premium duration to 1–10 users, distinguishing it from single-recipient alternatives and specifying the bulk scope. The verb 'Build' and resource 'order' are specific.

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

  Usage Guidelines3/5

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

  It implies bulk use ('1–10 users', 'ONE order') but never explicitly contrasts with single gifting or states when not to use. No alternative tools are mentioned, though siblings exist.

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

• hoton_topup_gramA
  3.7/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden. It discloses a key behavioral trait: 'Returns messages[] to sign with @ton/mcp', indicating the tool builds an order and returns a signing payload rather than directly executing the top-up. This adds meaningful context beyond the tool name, though it does not cover all side effects or prerequisites.

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

  Conciseness5/5

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

  Three short sentences, front-loaded with the core purpose. The first sentence states what it does, the second explains the output, and the third adds the restriction 'GRAM only'. No filler or repetition.

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

  Completeness2/5

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

  The tool has 4 parameters, a nested wallet object, and no output schema. The description does not explain the wallet parameter, the expected format of 'recipient' or 'amount', or the structure of the returned messages[]. While it mentions the return type, it leaves significant gaps for the agent to invoke the tool correctly, making it incomplete for a tool of this complexity.

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

  Parameters2/5

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

  Schema description coverage is only 25% (only 'referrer' has a description). The description adds no parameter-specific meaning: it does not clarify 'recipient', 'amount', or the nested 'wallet' object. While 'recipient' and 'amount' are somewhat self-explanatory from their names, 'wallet' is ambiguous and the description does not compensate for the low schema coverage.

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

  Purpose5/5

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

  The description states a specific action: 'Build an order to top up one Telegram account with GRAM (the native chain coin).' This clearly identifies the verb, resource, and scope. It distinguishes from siblings like hoton_topup_gram_bulk by specifying 'one Telegram account' and 'GRAM only'.

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

  Usage Guidelines3/5

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

  Usage context is implied through 'one Telegram account' and 'GRAM only', which suggests this is for single GRAM top-ups rather than bulk or other currencies. However, it does not explicitly name alternatives like hoton_topup_gram_bulk or state when not to use this tool, so the guidance remains implicit rather than explicit.

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

• hoton_topup_gram_bulkA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description must carry full behavioral disclosure. It does reveal that the tool 'Builds ONE order' and 'returns messages[] to sign', indicating an intermediate step rather than a direct execution. But it omits other behavioral traits such as prerequisites (wallet setup, recipient validation), reversibility, failure modes, and any side effects beyond creating an order.

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

  Conciseness5/5

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

  The description is three short sentences, each adding essential information: the action and scope, the return value, and the coin restriction. It is front-loaded and contains no filler or repetition, making it highly concise and well-structured.

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

  Completeness3/5

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

  Given the absence of annotations and an output schema, the description provides necessary core information (order creation, return of messages to sign). However, it lacks context about the wallet parameter, the role of referrer, and the overall flow (e.g., that messages must be signed and possibly confirmed via hoton_confirm). This is a moderate-complexity tool, so the description is not fully complete for an agent to use it confidently.

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

  Parameters3/5

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

  Schema description coverage is low (25%, only referrer described). The description partially compensates by clarifying that 'the same GRAM amount each' applies to recipients, aligning with amountEach and the 1–10 limit. However, it does not explain the wallet object or referrer beyond the schema, leaving significant semantic gaps for optional parameters.

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

  Purpose5/5

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

  The description uses a specific verb ('Build ONE order') with a clear resource ('toping up 1–10 Telegram accounts') and a specified coin ('GRAM (native chain coin)'). It also distinguishes from sibling tools by emphasizing the bulk nature and 'GRAM only', contrasting with star/premium operations.

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

  Usage Guidelines4/5

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

  The description implies when to use this tool (for bulk GRAM topups of 1–10 accounts) and provides output usage guidance ('Returns messages[] to sign with @ton/mcp'). However, it does not explicitly name alternatives (e.g., hoton_topup_gram for a single account) or state exclusions like 'not for buying stars'.

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

• hoton_use_walletA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must disclose behavior. It states the tool stores the wallet identity for the session and is a one-time prerequisite. However, it doesn't disclose details like whether repeated calls overwrite, what happens on invalid address, or what the return value is. It adds some context ('from @ton/mcp') but leaves out potential edge cases.

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

  Conciseness5/5

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

  Two short sentences that are front-loaded with the primary action and context. No wasteful words, every clause adds value.

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

  Completeness4/5

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

  For a simple setup tool with no output schema, the description covers the purpose, session scoping, and call timing. It could mention expected return or error behavior, but with good schema coverage and clear context, it's sufficiently complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, with all four properties having descriptions in the schema. The description adds no additional parameter-level detail, relying on the schema. Baseline of 3 applies due to full schema coverage.

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

  Purpose5/5

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

  The description uses a specific verb 'Store' and identifies the resource (TON wallet identity) and its purpose (for buy tools). It clearly distinguishes from sibling buy tools by positioning itself as a prerequisite setup step. The title reinforces the same, but the description adds clarity about session scope and source.

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

  Usage Guidelines4/5

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

  The description explicitly states when to call this tool ('Call this once before buying'), establishing it as a prerequisite. It explains the value proposition (so buy tools can target it), but doesn't explicitly mention alternatives or exclusions. This is clear enough for an agent to know this is a setup step before purchase tools.

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

• hoton_buy_starsA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that the tool builds an order rather than directly purchasing, and that it returns messages for signing—an important behavioral nuance. It also mentions referrer extraction. It omits error cases or prerequisites, but the core behavior is transparent.

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

  Conciseness5/5

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

  The description is only two sentences, front-loads the primary purpose, and each sentence adds value: what the tool does and what it returns. There is no filler or redundancy.

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

  Completeness4/5

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

  The description gives a sufficient high-level view: it builds an order, returns signable messages, and mentions referrer extraction. Given the detailed schema and five parameters, the description doesn't need to explain every parameter. It could mention that this is a pre-confirmation step, but the reference to signing with @ton/mcp covers that.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents each parameter (amount, wallet, payToken, recipient, referrer). The description adds only a context about referrer extraction, which complements the schema but doesn't significantly expand on parameter meaning beyond what is already present.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Build an order to send Stars to one Telegram user.' It distinguishes from the bulk sibling by emphasizing 'one Telegram user' and explicitly notes the output ('Returns messages[] to sign with @ton/mcp'), which is a specific and concrete outcome.

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

  Usage Guidelines4/5

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

  It indicates the tool is for a single recipient, differentiating it from the bulk variant. It also provides a usage hint: 'Extract a referrer from the user's prompt if they named one.' However, it does not explicitly mention when to avoid this tool (e.g., multiple recipients) or name alternative tools, though the context makes it clear.

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

• hoton_buy_stars_bulkA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of disclosure. It usefully reveals that the tool returns messages[] to sign with @ton/mcp rather than executing directly, and that it creates a single consolidated order. It does not mention prerequisites like an active session wallet, but the core behavior is clearly disclosed.

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

  Conciseness5/5

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

  The description is two concise sentences, front-loading the core purpose and then adding the key output behavior. Every word earns its place, with no redundancy or filler.

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

  Completeness4/5

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

  Given the tool has no output schema, the description adequately explains the return format (messages[]) and the single-transaction aspect. It is slightly light on preconditions like wallet setup, but the complexity level and sibling context make it sufficiently complete for correct selection and invocation.

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

  Parameters3/5

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

  The schema covers 100% of parameters with thorough descriptions, including enums, minimums, and array bounds. The main description adds minimal semantic value beyond the schema, only clarifying that the same amount applies to all recipients, which is expected. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description explicitly states the tool builds one order to send the same star amount to 1–10 users, clearly distinguishing it from the single-recipient hoton_buy_stars sibling. The verb 'Build' and the scope '1–10' make the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description clearly implies the bulk use case for multiple recipients, and the 1–10 range signals when to use it. However, it does not explicitly mention alternatives like hoton_buy_stars for single recipients or state exclusions, though the context is sufficient for an agent to decide.

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

• hoton_find_recipientA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the return values ('returns display name + photo') and clarifies the optional 'months' parameter for premium. It does not mention side effects or error scenarios, but for a simple lookup tool, the key behavioral traits are conveyed adequately.

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

  Conciseness5/5

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

  The description is extremely concise: two sentences that front-load the primary purpose and then add relevant details. Every word earns its place, with no redundancy or filler.

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

  Completeness4/5

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

  The tool is simple with 3 parameters and no output schema. The description covers the purpose, the context of use, and what it returns. It omits error cases or edge behaviors, but these are likely non-critical for a lookup tool, making the description sufficiently complete for the tool's complexity.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema, such as 'For premium, pass months' which aligns with the existing enum. It does not add new semantic depth for username or product, but it is not misleading.

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

  Purpose5/5

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

  The description clearly states the verb 'Look up' and the resource 'a Telegram @username', with a specific purpose ('before buying, to confirm the right person'). It also differentiates from sibling buy tools by noting 'buy tools also resolve usernames themselves', making it distinct.

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

  Usage Guidelines4/5

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

  The description provides clear usage context: 'before buying' to verify the recipient. It also notes that this is optional because 'buy tools also resolve usernames themselves', which implies alternatives. However, it does not explicitly state when not to use or provide direct comparison with sibling tools, but the guidance is sufficient.

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

• hoton_confirmA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It states that the purchase settles on-chain at signing, so confirm failures don't indicate a failed purchase, preventing duplicate buys. It also transparently mentions the side effects of recording history/referral and that it polls the chain, which adds value beyond the raw schema.

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

  Conciseness5/5

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

  The description is three sentences long and front-loaded with the required call order. It efficiently packs the tool's purpose, workflow context, and a safety warning with no fluff or repetition.

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

  Completeness5/5

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

  For a tool with no output schema and straightforward inputs, the description is complete: it states when to call, what to pass, what it returns (delivery status + tonviewer link), and how to handle failures. This gives the agent all operational knowledge needed to use the tool correctly in context.

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

  Parameters3/5

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

  The schema already covers all 4 parameters with 100% description coverage, including that expectedAmount comes from the buy result and is used to pinpoint the transaction. The description reinforces 'Pass `expectedAmount` from the buy result' but adds no new semantic information beyond what the schema provides, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's function: it polls the TON chain for a settled transaction, returns delivery status and a tonviewer link, and records the result in Hoton's history and referral. It distinguishes itself from sibling buy/wallet tools by explicitly positioning it as the post-signing confirmation step.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use guidance: 'Call after @ton/mcp send_raw_transaction signs the order.' It also provides critical failure handling advice—'a failure here never means you should re-buy — just retry confirm'—which prevents the agent from taking an incorrect alternative action.

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

• hoton_statusA
  4.7/5.0
  Behavior4/5

  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 discloses that this is a read-only health check and instructs how to interpret an unhealthy response. It does not elaborate on what 'healthy' means or error behavior, but for a zero-parameter status check this is adequate.

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

  Conciseness5/5

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

  Two sentences, with the first stating purpose and the second providing usage guidance. No filler, immediately scannable, and appropriately sized for the tool's simplicity.

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

  Completeness5/5

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

  For a simple status check with no params and no output schema, the description fully covers what it does, when to use it, and how to act on the result. It is complete in context: all siblings are actions, so this stands out as the preflight health gate.

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

  Parameters4/5

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

  The tool has zero parameters, so there is nothing for the description to explain. The schema is empty and fully covered, and the description adds no parameter details, but none are needed.

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

  Purpose5/5

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

  The description clearly states the tool returns whether Hoton/Fragment is healthy, which is a specific verb and resource. It is immediately distinguishable from all sibling tools, which are purchase/wallet operations.

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

  Usage Guidelines5/5

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

  The description explicitly tells when to call ('before buying if unsure') and what to do with the result ('if unhealthy, tell the user to try later instead of buying'). This is direct and actionable.

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

• hoton_use_referrerA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the main behavioral effect (35% commission credited) and the house link behavior. However, it does not explicitly state whether the setting persists across calls or any error handling for invalid referrers, but the core behavior is 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.

  Conciseness5/5

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

  The description is three concise sentences with no fluff. It front-loads the action, provides an example, and includes usage guidance. Every sentence contributes value, making it appropriately sized for the tool's simplicity.

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

  Completeness5/5

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

  For a single-parameter, no-annotation, no-output-schema tool, the description covers purpose, usage, and behavioral effect sufficiently. It explains the meaning of house link and the commission impact, making it complete for an AI agent to invoke correctly.

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

  Parameters4/5

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

  The schema already describes the referrer parameter at 100% coverage. The description adds useful context: the commission rate, the example format, and the condition for setting it. This enhances understanding beyond the schema's raw type description.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: to set a referral link/short-name/wallet for crediting referrer commission on subsequent purchases. It uses a specific verb ('Set') and resource ('referrer'), distinguishes from sibling tools like hoton_use_wallet, and provides an example. The scope ('this session') is in the title.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use the tool: 'Only set this if the user named a referrer.' It also explains the house link as an alternative that means no commission, effectively covering when-not-to-set or an alternative value. This is clear usage guidance.

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