Server Quality Checklist

Tool Scores

• create_rewardC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure but fails to deliver. It does not specify what the tool returns (reward ID? full object?), error conditions, idempotency behavior, or side effects. The phrase 'redeemable with loyalty tokens' offers minimal context about the cost mechanism but lacks operational details.

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

  Conciseness4/5

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

  The description is a single, efficient sentence of seven words with no redundancy. It is front-loaded with the action verb. However, given the lack of annotations and output schema, the 'appropriate size' criterion suggests it may be overly terse for the complexity of a resource creation operation.

  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?

  For a creation tool with four parameters and no output schema or annotations, the description is insufficient. It fails to explain the return value (critical for creation operations), the relationship between the reward and existing loyalty programs (implied by token_address), or behavioral constraints. The agent lacks sufficient context to handle error cases or understand the full lifecycle implications.

  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 input schema has 100% description coverage ('Token contract address', 'Token cost to redeem', etc.), establishing a baseline of 3. The description adds semantic framing that the reward is 'redeemable with loyalty tokens,' which helps connect the 'token_address' and 'cost' parameters conceptually, but does not add syntax details, validation rules, or format specifications beyond the schema.

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

  Purpose4/5

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

  The description clearly states the action ('Create') and resource ('reward'), and specifies the domain context ('redeemable with loyalty tokens') which distinguishes it from creating loyalty programs or minting tokens. However, it does not explicitly differentiate from sibling 'list_rewards' or 'redeem_reward' beyond the implied verb difference.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'redeem_reward' or 'list_rewards'. It omits prerequisites (e.g., whether an active loyalty program must exist first) and does not mention required permissions or admin privileges typically needed for reward creation.

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

• list_marketplace_offersC
  2.9/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. It fails to disclose whether this is read-only (though implied by 'List'), pagination behavior beyond the limit parameter, rate limits, or what 'marketplace' means in the context of the loyalty ecosystem. The 'active' qualifier suggests default behavior but doesn't clarify if this is a default filter.

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

  Conciseness4/5

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

  Single sentence of 8 words is appropriately front-loaded with no filler. However, given zero annotations and no output schema, the description is overly terse—additional sentences explaining behavior or return format would earn their place.

  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?

  For a 2-parameter tool with full schema coverage, the description covers the minimum. However, gaps remain: no explanation of how marketplace offers relate to the loyalty token ecosystem (siblings include mint/transfer tokens), no output format details, and the 'active' ambiguity leaves functional scope slightly unclear.

  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 has 100% description coverage, establishing baseline 3. The description mentions 'active' which loosely maps to the status parameter, but adds no detail on the limit parameter's usage, valid status enum values, or parameter interactions. Does not compensate for lack of output schema.

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

  Purpose4/5

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

  Clear verb (List) and resource (token trading offers on marketplace) distinguishes this from loyalty-program siblings. However, stating 'active' in the description is slightly confusing since the status parameter allows filtering by completed/cancelled as well, implying the tool can list non-active offers too.

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

  Usage Guidelines2/5

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

  No guidance on when to use this versus list_loyalty_programs or other list tools. No mention of prerequisites (e.g., whether user needs specific permissions to view marketplace offers) or when to filter by specific statuses.

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

• list_rewardsC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure but only implies read-only safety through the verb 'List'. It fails to mention pagination behavior, rate limiting, authentication requirements, or what data structure is returned (rewards as objects, array, etc.).

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

  Conciseness4/5

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

  The description is extremely concise at 9 words with no filler content. However, given the absence of annotations and output schema, this brevity may be excessive—every sentence earns its place, but there aren't enough sentences to fully document the tool's behavior.

  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?

  For a single-parameter tool with 100% schema coverage, the description meets minimum viability by identifying the core operation. However, given no output schema and no annotations, it should explain what constitutes a 'reward' or provide return value context to be complete. It stops at the bare minimum.

  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 coverage is 100%, so the baseline is 3. The description acknowledges the 'token_address' parameter but adds no semantic value beyond the schema's description ('Token contract address (0x...)'). It doesn't clarify if this is the program's token or a specific reward token.

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

  Purpose4/5

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

  The description clearly states the verb (List), resource (rewards), and scope (for a loyalty program), which distinguishes it from sibling tools like 'create_reward' or 'list_loyalty_programs'. However, it doesn't clarify the relationship to 'list_marketplace_offers' or what distinguishes a 'reward' from an 'offer' in this domain.

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

  Usage Guidelines2/5

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

  The description mentions the filter criterion ('by token_address') but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites for the token_address value. It lacks 'when-not' guidance or context about program states (e.g., active vs. inactive programs).

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

• register_loyalty_programC
  2.9/5.0
  Behavior2/5

  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 mentions persistence ('in the database') but fails to clarify critical behavioral traits: whether this is idempotent, what gets returned (no output schema exists), error conditions (e.g., duplicate registration), or side effects. For a database mutation operation, this is insufficient behavioral coverage.

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

  Conciseness4/5

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

  Single sentence is efficient and front-loaded with the core action. However, given the absence of annotations and output schema, the description is arguably too brief—conciseness becomes under-specification when critical behavioral and sibling-differentiation context is missing.

  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 zero annotations, no output schema, and a confusingly similar sibling tool ('create_loyalty_program'), the description is incomplete. It should explicitly clarify the distinction between creating new programs versus registering existing deployed tokens, and disclose return values or success indicators.

  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?

  Input schema has 100% description coverage, establishing a baseline of 3. The description reinforces 'token_address' by mentioning 'deployed token' but adds no additional semantic context (e.g., address format validation, default behavior when expiration_days is omitted) beyond what the schema already provides.

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

  Purpose4/5

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

  The description states a specific action ('Register') and resource ('deployed token' as 'loyalty program'), clarifying this handles existing tokens. However, it lacks explicit differentiation from the sibling 'create_loyalty_program', which could confuse agents about whether to deploy new tokens or register existing ones.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus 'create_loyalty_program' or other alternatives. While 'deployed token' implies prior token deployment, there are no 'when-to-use' or 'when-not-to-use' instructions, nor prerequisites stated (e.g., token ownership verification).

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

• transfer_loyalty_tokensC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get calldata' implies a read-only/preparation operation, the description fails to specify the return format (hex string, JSON object), whether validation occurs (balance checks), or any rate limiting concerns.

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

  Conciseness4/5

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

  The description is a single, efficient sentence with no redundant words. It front-loads the action ('Get calldata') and maintains focus. However, it may be overly terse given the complexity of blockchain transaction preparation, lacking a second sentence to clarify the output or next steps.

  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?

  For a tool generating blockchain transaction data, the description omits crucial context: the nature of the returned calldata, whether it includes gas estimates, and how to use the result. With no output schema and no annotations, the description should compensate by explaining the transaction preparation workflow, which it does not.

  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 input schema has 100% description coverage with clear Ethereum address formats and amount specification. The description adds minimal semantic value beyond the schema, merely contextualizing that the transfer occurs 'between wallets', which aligns with the 'to' parameter. Baseline 3 is appropriate given comprehensive schema documentation.

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

  Purpose4/5

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

  The description clearly specifies the action ('Get calldata'), resource ('loyalty tokens'), and operation ('transfer between wallets'). It implicitly distinguishes from execution-style transfers by specifying 'Get calldata', though it doesn't explicitly contrast with sibling tools like 'mint_loyalty_tokens'.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, nor does it explain the critical workflow that this generates unsigned transaction data requiring separate signing and submission. No prerequisites or exclusion criteria are mentioned.

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

• get_platform_infoB
  3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. While it mentions 'Base L2' indicating blockchain context, it fails to disclose whether this is read-only, what specific protocol data is returned (addresses, versions, parameters), or any authentication requirements.

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

  Conciseness4/5

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

  Extremely concise at only seven words. The information is front-loaded and there is no repetition of structured data, though the brevity borders on under-specification for a complex blockchain protocol tool.

  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?

  Without an output schema or annotations, and given the complexity of L2 protocol interactions, the description is insufficient. 'Get info' is too vague—it should specify what platform information is retrieved (e.g., contract addresses, protocol version, supported features).

  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 input schema has zero parameters. Per scoring rules, zero parameters establishes a baseline of 4 since there are no parameter semantics to describe beyond what the empty schema already conveys.

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

  Purpose4/5

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

  The description uses a clear verb ('Get info') and identifies the specific resource ('Loyal Spark protocol') and context ('Base L2'). It distinguishes from siblings by targeting the protocol infrastructure rather than specific loyalty programs or operations.

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

  Usage Guidelines2/5

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

  No guidance provided on when to use this versus other tools. Given siblings like get_my_profile or get_token_balance, the agent would benefit from knowing whether this returns global protocol metadata or user-specific data.

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

• get_program_analyticsB
  3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure but fails to state whether this is read-only, if it requires specific permissions, whether data is real-time or cached, or the expected data volume. The verb 'Get' weakly implies a safe read operation, but this is insufficient for a data retrieval tool without output schema documentation.

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

  Conciseness4/5

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

  The description is a single, efficient sentence with no wasted words. However, given the lack of output schema and annotations, it is arguably under-specified rather than optimally concise—it leaves critical behavioral and return-value information unstated.

  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 no output schema, no annotations, and zero parameters, the description should explain what analytics are returned (metrics, time periods, aggregation levels) and how to interpret them. It currently provides only a high-level label without the necessary detail to use the tool effectively.

  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 input schema contains zero parameters, establishing a baseline score of 4. The description implies the scope ('your loyalty programs' plural) suggests analytics for all user programs are returned, adding minimal semantic context about the implicit filtering, though it doesn't explain how program selection works.

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

  Purpose4/5

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

  The description uses a specific verb ('Get') and identifies the resource ('analytics for your loyalty programs'), clarifying this retrieves statistical data rather than program configurations. It implicitly distinguishes from sibling 'list_loyalty_programs' by focusing on analytics rather than program metadata, though it lacks specificity about what metrics are included.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'list_loyalty_programs' or prerequisites such as having active loyalty programs. There are no exclusions, context requirements, or workflow positioning hints.

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

• list_loyalty_programsB
  3.1/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. It discloses ownership filtering ('owned by the agent's merchant') but fails to confirm read-only safety, pagination behavior, return format, or rate limits. 'List' implies non-destructive, but this should be explicit without annotations.

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

  Conciseness5/5

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

  Single sentence (7 words), front-loaded with action verb, zero redundancy. Every word earns its place.

  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?

  Tool has low complexity (1 optional param, no nesting). Description covers core purpose but lacks behavioral context expected when no annotations or output schema exist. Adequate but minimal for agent confidence.

  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 has 100% description coverage for the single 'include_expired' parameter. The description doesn't mention this parameter, but with complete schema documentation, no additional compensation is needed. Baseline score appropriate.

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

  Purpose4/5

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

  Clear verb 'List' with specific resource 'loyalty programs' and ownership scope 'owned by the agent's merchant'. This scope helps distinguish from siblings like list_marketplace_offers, though it doesn't explicitly contrast with create_loyalty_program or register_loyalty_program.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use versus alternatives (e.g., when to list vs. create/register). The verb 'List' implies retrieval, but there are no when-not-to-use conditions or workflow guidance provided.

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

• mint_loyalty_tokensB
  3.1/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full disclosure burden. It crucially clarifies that this tool returns 'smart contract call params' rather than executing the transaction itself—a key behavioral distinction. However, it omits authentication requirements, gas/fee implications, idempotency guarantees, or what the returned parameters contain.

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

  Conciseness4/5

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

  The description is extremely concise at nine words with no filler. It front-loads the core action. However, given the high-stakes blockchain context and zero annotations, it is arguably too terse—lacking safety warnings or output handling guidance that would justify its brevity.

  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?

  For a blockchain operation tool with no output schema and no annotations, the description is insufficient. While it mentions returning 'smart contract call params,' it fails to describe the output structure, error cases, chain/network context, or how to use the returned parameters to actually execute the mint.

  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 input schema has 100% description coverage for all three parameters (token_address, recipient, amount), establishing a baseline score of 3. The description adds no additional semantic context beyond what the schema already provides, such as address format validation or amount precision requirements.

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

  Purpose4/5

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

  The description clearly states the tool records minting intent and retrieves smart contract parameters, using specific verbs ('record', 'get') and identifying the blockchain context. However, it does not explicitly differentiate from the sibling 'transfer_loyalty_tokens' tool, which also moves tokens to recipients but from existing supply rather than minting new ones.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this versus 'transfer_loyalty_tokens' or other alternatives. There are no prerequisites mentioned (e.g., program ownership requirements) nor warnings about the irreversible nature of minting operations in blockchain contexts.

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

• get_token_balanceB
  3.2/5.0
  Behavior3/5

  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 tool returns both balance and tier information (not just a numeric balance), but fails to mention read-only safety, idempotency, error cases (e.g., invalid addresses), or rate limits.

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

  Conciseness4/5

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

  The single sentence is front-loaded with the verb 'Get' and contains no redundant words. However, extreme brevity comes at the cost of omitting important contextual details about behavior and return values.

  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?

  For a two-parameter read operation with complete input schema coverage, the description minimally suffices by mentioning the two data points returned (balance and tier). However, without an output schema, it should ideally describe the return structure or format, which it omits.

  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%, establishing a baseline of 3. The description maps 'loyalty token' to token_address and 'customer' to customer_address implicitly, but adds no semantic details about address formats, validation rules, or the relationship between the two addresses.

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

  Purpose4/5

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

  The description clearly states the tool retrieves 'loyalty token balance and tier info' using specific verbs and resources. However, it lacks explicit differentiation from sibling read tools like check_voucher_status or get_program_analytics.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like check_voucher_status or get_program_analytics, nor does it specify prerequisites (e.g., whether the customer must be registered first).

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

• get_my_profileB
  3.3/5.0
  Behavior3/5

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

  No annotations provided, so description carries full disclosure burden. The phrase 'authenticated agent' implies authentication is required, which is valuable context. However, lacks details on what profile fields are returned, caching behavior, or rate limits.

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

  Conciseness4/5

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

  Extremely concise at five words. Front-loaded with verb-first structure. No redundant text, though appropriate for a simple parameter-less tool. Could benefit from one additional clause describing return value.

  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?

  Adequate for a low-complexity tool with no parameters. However, lacks output schema documentation, so description should ideally hint at what profile data is returned (ID, permissions, metadata) to complete the mental model.

  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?

  Input schema has zero parameters, establishing baseline score of 4. Description appropriately signals no inputs are required by omitting parameter discussion.

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

  Purpose4/5

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

  States a clear verb ('Get') and specific resource ('authenticated agent's profile'). Effectively distinguishes from sibling tools which focus on loyalty programs, vouchers, and tokens rather than agent identity.

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

  Usage Guidelines2/5

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

  Provides no guidance on when to use this tool versus alternatives, or what operations should precede/follow it. No mention of why an agent would need to retrieve their profile (e.g., verification before transactions).

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

• create_loyalty_programA
  3.5/5.0
  Behavior3/5

  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 the mechanism (factory calldata) and platform (Base), but lacks details on side effects, authentication requirements, rate limits, or what the tool actually returns (the calldata itself vs a transaction hash).

  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?

  Single, dense sentence with zero waste. Front-loaded with action ('Get factory calldata'), specifies the domain ('ERC-20 loyalty token'), and platform ('Base'). Every word earns its place.

  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?

  For a blockchain deployment tool with 100% schema coverage, the description adequately covers the primary purpose. However, lacking an output schema and given the complexity of factory deployment patterns, it should ideally clarify what the caller receives (calldata vs deployed address) and next steps. Sufficient but not comprehensive.

  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 coverage is 100% with clear descriptions for all 3 parameters (name, symbol, expiration_days). The description provides context that these params are for an ERC-20 loyalty token, but does not add specific syntax or format details beyond what the schema already provides. 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?

  Specific verb 'Get factory calldata' combined with clear resource 'ERC-20 loyalty token' and platform 'Base'. Distinguishes from sibling tools like register_loyalty_program or activate_loyalty_program through the specific deployment mechanism.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this versus siblings like register_loyalty_program or activate_loyalty_program. While 'deploy' implies initial contract creation, the workflow relationship between deploying, registering, and activating is not explained.

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

• update_program_statusA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully clarifies that this operates on the database (not the blockchain), which is critical context. However, it omits details about idempotency, error handling if the on-chain state differs, or what the function returns.

  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 a single, efficient sentence of nine words with no filler. It front-loads the action ('Update program status') and every word contributes essential information about scope and timing.

  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?

  For a two-parameter mutation tool without output schema or annotations, the description is minimally sufficient. It explains the 'where' (database) and 'when' (after on-chain events), but lacks information about success indicators, failure modes, or state validation requirements that would make it fully 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?

  The input schema has 100% description coverage, establishing a baseline of 3. The description adds workflow context ('after on-chain activation/pause') that semantically links the 'status' parameter values (active/paused) to their on-chain counterparts, but does not elaborate on token address format or validation rules beyond the schema.

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

  Purpose4/5

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

  The description clearly states the action (Update), resource (program status in database), and scope limitation (after on-chain activation/pause). It effectively distinguishes this database-sync tool from the sibling 'activate_loyalty_program' by specifying 'database' and 'after on-chain', though it could explicitly name the sibling to be perfect.

  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?

  The phrase 'after on-chain activation/pause' provides implicit temporal guidance for when to invoke this tool (i.e., following blockchain state changes). However, it lacks explicit contrast with alternatives like 'activate_loyalty_program' or clear statements 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.

• activate_loyalty_programA
  3.6/5.0
  Behavior3/5

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

  Without annotations, the description carries the burden of explaining behavior. It successfully clarifies that this returns calldata (transaction data) rather than executing the activation itself, and discloses the specific operations involved. However, it omits safety considerations, error conditions (e.g., already active programs), or authentication requirements.

  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?

  Single, efficient sentence with high information density. The parenthetical technical details (unpauseUtility + enableMinting) are precisely placed to clarify the calldata content without verbosity. No wasted words.

  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 low complexity (1 param, no nesting) and no output schema, the description adequately explains the return value (calldata) and the target state. It meets the minimum requirements for this tool's complexity level, though annotations or error conditions would improve it further.

  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?

  With 100% schema coverage, the baseline is 3. The description adds implicit context that token_address refers to an inactive program's contract, but does not elaborate on parameter format beyond the schema's '0x...' notation or provide examples.

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

  Purpose4/5

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

  The description clearly states the tool 'Gets activation calldata' using specific technical terms (unpauseUtility + enableMinting) and specifies the target resource (inactive program). However, it does not explicitly differentiate from the sibling tool update_program_status, which could create selection ambiguity.

  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 preconditions by specifying 'for an inactive program,' but provides no explicit guidance on when to use this versus update_program_status or other sibling tools, and does not state what happens if the program is already active.

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

• redeem_rewardA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully discloses that the tool 'Creates a voucher' as a side effect and implies validation of the transaction hash. However, it omits critical behavioral details such as error handling for invalid hashes, idempotency guarantees, or whether the voucher creation is synchronous.

  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 consists of two highly efficient sentences with zero redundancy. It front-loads the core action and mechanism in the first sentence and follows with the outcome/side effect, making it immediately scannable and actionable.

  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 absence of annotations and output schema, the description adequately covers the primary workflow: it explains the redemption mechanism, the required blockchain context, and the voucher creation outcome. It could be improved by describing the return value structure or error conditions, but it provides sufficient context for correct 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 input schema has 100% description coverage, establishing a baseline score of 3. The description adds minimal semantic value beyond the schema, though it reinforces the relationship between parameters by specifying that the transaction_hash must represent a 'verified token transfer.' It does not add syntax details, validation rules, or format examples beyond what the schema provides.

  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 specific action ('Redeem a reward'), the required mechanism ('by providing a verified token transfer transaction hash'), and the outcome ('Creates a voucher'). It effectively distinguishes from siblings like 'create_reward' (which creates the reward definition) and 'use_voucher' (which likely consumes vouchers).

  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?

  The description implies usage context through the requirement of a 'verified token transfer transaction hash,' suggesting this tool is for post-payment verification scenarios. However, it lacks explicit guidance on when to use this versus 'use_voucher' or what prerequisites must be met before invocation.

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

• check_voucher_statusA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully documents authentication requirements (public, no key needed), but does not explicitly confirm this is a read-only operation, describe potential rate limits, or explain what status values (valid, used, expired) might be returned.

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

  Conciseness5/5

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

  The description consists of two efficient sentences with zero redundancy. The first sentence front-loads the core purpose and parameters, while the second provides critical authentication context. Every word earns its place.

  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 lookup tool with two optional parameters and no output schema, the description adequately covers purpose, inputs, and authentication requirements. It appropriately omits redundant return value explanation given the self-documenting tool name, though it could benefit from explicitly stating the read-only nature of the operation.

  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 input schema has 100% description coverage, establishing a baseline of 3. The description adds marginal value by noting the parameters are alternatives ('code or ID'), but does not elaborate on syntax details beyond the schema's example format for the code parameter.

  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 provides a specific verb ('Check'), resource ('voucher status'), and identification methods ('by code or ID'), clearly distinguishing it from the sibling 'use_voucher' tool through the semantic difference between checking status versus using/consuming the voucher.

  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 explicit usage context by disclosing 'Public endpoint — no API key or authentication required,' which signals when to use this tool (for unauthenticated lookups). However, it does not explicitly reference sibling 'use_voucher' as the alternative for redeeming the voucher, which would prevent confusion between reading and mutating operations.

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

• use_voucherA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full disclosure burden. It explains the business scenario (customer redemption at merchant) and implies a state mutation, but omits technical behavioral details such as idempotency, error conditions (e.g., already-used vouchers), or authentication requirements beyond the merchant scope.

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

  Conciseness5/5

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

  Two sentences with zero waste: the first establishes the action and business context, the second establishes the authorization boundary. Information is front-loaded and every word earns its place.

  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 two-parameter state-change tool without an output schema, the description adequately covers the essential context: what it does, who performs it, and the business scenario. Minor gap: it could clarify the mutual exclusivity requirement of the two parameters (use code OR id).

  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%, documenting both voucher_code and voucher_id. The description adds no specific parameter guidance beyond what the schema already provides (e.g., it doesn't clarify that exactly one identifier is required despite both being technically optional in the schema).

  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 specific action ('Mark a voucher as used'), the resource (voucher), and the context ('redeemed by customer at merchant'). The 'Merchant-only operation' clause effectively distinguishes this from customer-facing redemption tools like 'redeem_reward' in the sibling list.

  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 'Merchant-only operation' text provides clear guidance on the required authorization context and actor role. However, it lacks explicit prerequisites (e.g., suggesting to use 'check_voucher_status' first) or exclusion conditions (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.