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 does disclose that this is a wrapper around track_event with admin context and that an audit trail exists, but it omits whether the reward is irreversible, what permissions are required, and any rate/duplication constraints — meaningful gaps for a mutation tool.

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

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

Three short sentences, front-loaded with the core action and the wrapper detail, with a docs reference at the end. Every sentence earns its place, though the 'See also' pointer is of marginal value.

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

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

For an 8-parameter mutation tool with no annotations and no output schema, the description covers purpose and admin context but leaves the return behavior, side effects, and the relationship to the sibling track_event largely unexplained. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters (amount override, reason, adminId, brandId fallback, etc.). The description adds no syntax, format, or fallback detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb+resource ('Manually reward users') and immediately distinguishes itself from siblings by describing itself as an admin-context 'Wrapper around track_event'. An agent can tell it apart from loyalteez_track_event and loyalteez_log_activity.

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

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

Gives explicit context: 'Use this when admins want to manually reward users for special contributions.' The wrapper framing implies the alternative (tracking an event directly) but never states when NOT to use this versus loyalteez_track_event, so it stops short of the 5-level routing clarity.

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

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

No annotations are supplied, so the description carries the full burden and falls short. For a bulk mutation it says nothing about partial-failure behavior, per-event error reporting, idempotency, auth requirements, or rate limits — the operational facts an agent most needs before submitting 100 events.

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

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

Three tight sentences with the core action front-loaded and no redundancy. The trailing documentation link is low value but harmless.

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

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

A batch write with no annotations and no output schema needs more than this: the response shape and partial-failure semantics are entirely absent. The max-100 constraint is at least recoverable from the schema.

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

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

Schema description coverage is 100% and the single nested array is well documented, including the maxItems=100 cap and the brandId inheritance note. The description adds no parameter detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource: 'Submit multiple events in a single request,' which is unambiguous about the bulk nature. However, it never distinguishes itself from the near-identical sibling 'loyalteez_create_events_batch', which an agent must choose between.

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

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

Gives clear positive contexts (batch processing, historical import, high-volume integrations) and names track_event as the less-efficient alternative. Missing the more important exclusion: why this exists alongside create_events_batch.

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

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

With no annotations, the description carries full burden and does well: it discloses the return breakdown, multiplier ranges (1.0-5.0x), flat bonus bounds (0-1000 LTZ), and the three stacking modes. It stops short of clarifying whether the call is a pure computation or has side effects on the user's balance.

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

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

Front-loaded with the core action, kept to three tight sentences plus a doc pointer. The second paragraph is dense but every clause adds behavioral context rather than filler.

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

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

For a 6-parameter calculation tool with complete schema coverage and no output schema, the description covers return contents, bonus arithmetic, and stacking rules. The main gap is whether the operation is read-only or mutates reward state.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds useful semantics about how the `roles` parameter is interpreted (stacking mode, multiplier vs flat bonus), but nothing beyond the schema for the other five parameters.

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

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

States a specific verb (Calculate) and resource (final reward) plus the scope of inputs (role multipliers & bonuses) and the return shape. It is clearly distinguishable from state-changing siblings like log_activity or claim_drop, though it never explicitly names a conflicting alternative.

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

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

The description never says when to call this versus alternatives such as admin_reward, check_eligibility, or track_event. It points to a docs resource but gives no conditions for use, exclusions, or prerequisites (e.g. whether the event must already exist).

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

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

With no annotations, the description carries the full burden and does reasonably well: it enumerates what comes back (eligibility status, cooldown info, claim history) and discloses a degraded-mode workaround via get_event_config. It stops short of stating read-only/non-mutating semantics explicitly or any auth requirements.

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

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

Front-loads the core purpose in the first sentence, then adds return contents and a fallback procedure. The implementation note is long but earns its place by enabling a manual fallback; still, it could be tightened.

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

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

There is no output schema, so the description usefully names the return fields, and it points to the REST API doc reference for deeper detail. The main missing piece is how it relates to the sibling perk-eligibility tool.

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

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

All three parameters are already documented at 100% schema coverage, including the brandId env-var fallback and eventType/userEmail meaning. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (check) and resource (eligibility for a reward on a specific event), and explicitly distinguishes it from the tracking path by saying to use it BEFORE loyalteez_track_event. An agent can tell it apart from the other event-mutating siblings.

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

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

Gives clear usage timing: call before tracking an event to validate reward eligibility, plus a fallback procedure when the endpoint is unavailable. It does not, however, distinguish this from the near-neighbor loyalteez_check_perk_eligibility, so the alternative selection is incomplete.

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

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

No annotations are provided, so the description carries the behavioral burden. It usefully discloses the return shape (eligibility status, balance check, cost, missing amount), but does not state permissions, whether the operation has any side effects, or rate limits for a tool that may query external services.

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

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

Front-loaded with the core action and return fields in two tight sentences. The documentation link is relevant and short, though slightly tangential to direct invocation guidance.

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

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

With no output schema, the description usefully enumerates return fields and links to service documentation. It is nearly complete for a check-only tool, though it lacks auth/permission context and explicit relation to claim/redeem siblings.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the input schema. The description adds no parameter-specific meaning beyond what the schema provides, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb and resource: 'Check if user can claim a specific perk.' It is clearly a read-only eligibility check and distinct from redeem_perk, but it does not explicitly name or differentiate against sibling tools such as loyalteez_check_eligibility or loyalteez_redeem_perk.

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

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

The description implies this is a pre-claim check, but gives no explicit when-to-use guidance, no conditions for choosing it over redeem_perk or check_eligibility, and no prerequisites. The 'See also' link is documentation, not usage guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden for a mutation tool. It discloses the return payload (success status, reward amount, position, remaining claims), which is genuinely useful, but says nothing about idempotency, single-use claim semantics, required permissions, or failure modes.

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

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

Two tight sentences, front-loaded with the action and immediately followed by the return shape. No filler or restatement of the tool name.

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

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

With no output schema, the description usefully enumerates return fields, and the parameters are fully documented in the schema. However, for a state-changing claim operation with zero annotations, the absence of any eligibility, duplicate-claim, or error-behavior context leaves meaningful gaps.

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

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

Schema description coverage is 100%, with each of the three required parameters documented in the schema itself. The description adds no format or constraint detail beyond it, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Process a drop claim'), which is meaningfully distinct from siblings like create_drop and redeem_perk. It stops short of explicitly differentiating itself from those siblings, but the action is unambiguous.

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

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

No when-to-use condition, no prerequisites, and no mention of alternatives such as create_drop or redeem_perk. The only guidance is a pointer to external docs, which the agent cannot rely on as in-band routing information.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the return payload ('bonus LTZ amount awarded'), which is genuine value with no output schema, but for a mutation tool it says nothing about idempotency, what happens if the milestone has not been reached or was already claimed, or what permissions/brand context are required.

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

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

Two tightly-written sentences, front-loaded with the action and the valid inputs, then the return value, followed by a single reference link. Nothing is padded and nothing an agent needs at scan time is buried.

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

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

With a fully documented schema and no output schema, the description covers the call itself and the response shape. However, as an unannotated mutation tool it omits the eligibility/failure conditions an agent needs to invoke it safely, and the doc link only partially compensates.

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

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

Schema description coverage is 100%, including per-parameter docs, a default for streakType and an enum for milestoneDays, so the schema does the heavy lifting. The description repeats the milestone values already encoded in the enum but adds no format, identifier, or fallback semantics of its own — baseline 3 is correct.

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

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

States a specific verb+resource ('Claim a milestone bonus ... for a user's streak') and enumerates the exact valid milestones (7, 30, 100, 365 days). This distinguishes it from the sibling streak tools (streak_checkin, get_streak_status), which record or read streak state rather than redeem a milestone reward.

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

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

Usage is implied by the name and by '(7, 30, 100, 365 days)', but there is no explicit statement of when this should be called versus the siblings, nor any prerequisite (e.g. the streak must actually have reached the milestone, or that a milestone can only be claimed once). The 'See also' doc pointer gives the agent a route to further guidance, which lifts this above a bare 2.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the return payload (drop ID, claim URL, embed data) and the time-limited nature of the drop, but says nothing about required permissions, whether the drop is immediately live, or what happens when maxClaims/expiry are hit.

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

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

Two tight sentences: the creation action and drop types lead, the return payload follows, then a doc reference. No filler, everything front-loaded.

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

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

For a 10-parameter mutation tool with no annotations and no output schema, the description covers the return shape and the drop's lifecycle constraint, which is the most important missing structured information. It still omits auth/permission requirements and error behaviour, leaving a modest gap.

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

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

Schema description coverage is 100% across all 10 parameters, so the schema already documents reward, brandId, platform, serverId, eventType, triggerType, triggerEmoji, maxClaims and expiresInSeconds. The description adds no syntax or format detail beyond the schema, which is the baseline-3 case.

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

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

States a specific verb and resource (create reward drops) and clarifies the two drop flavours, reaction drops and claim buttons, plus time-limited scope. It does not explicitly contrast with the sibling loyalteez_claim_drop or loyalteez_create_event, so it is clear but not fully sibling-differentiated.

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

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

Usage is implied by 'for posting' and the pointer to the drops-service docs, which gives an agent a place to look. There is no explicit when-to-use vs when-not, nor any routing away from create_event or claim_drop, so guidance remains inferential.

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

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

With no annotations, the description carries the full behavioral burden, and it does add real value by sketching the downstream pipeline: 'fire event → check auth → reward from balance.' That tells the agent an auth check gates rewards. However it says nothing about permissions required to create events, idempotency/duplicate handling, rate limits, or error behavior for a mutation tool.

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

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

Two short sentences plus a doc link; the core action is front-loaded and nothing is wasted. The pipeline arrow notation is compact rather than verbose. Minor deduction because the 'infinitely flexible' phrasing is more promotional than informative.

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

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

For a mutation tool with no annotations, no output schema, and a deeply nested object parameter, the description does not cover return values, permission requirements, or failure modes, relying instead on the external docs link. It is adequate for the happy path but leaves the agent under-informed about edge behavior.

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

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

Schema description coverage is 100% and each nested field (name, defaultReward, maxClaimsPerUser, detectionMethods, etc.) is documented in the schema itself, so the baseline is 3. The description adds no parameter-level detail beyond what the schema already provides, such as which fields are optional vs required.

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

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

States a specific verb+resource: 'Create a custom event for your loyalty program.' The follow-up sentence clarifies that any string can serve as an event type, which distinguishes this config-creation tool from runtime siblings like loyalteez_track_event. It stops short of explicitly naming the closest alternative, loyalteez_create_events_batch.

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

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

There is no explicit when-to-use guidance and no named alternative, despite a sibling (loyalteez_create_events_batch) that clearly overlaps. The 'See also' doc pointer gestures at further context but doesn't state selection criteria or prerequisites. Usage is only weakly implied by 'Create a custom event'.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return content (all created events plus platform-specific implementation code), but says nothing about atomicity (all-or-nothing vs. partial failure), permission/auth requirements, or duplicate handling — significant gaps for a batch mutation.

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

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

Three short, front-loaded segments with the core action first, followed by the use case, the return content, and a doc link. 'Perfect for setting up entire programs' is mild marketing filler, but nothing is bloated or buried.

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

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

There is no output schema, so the description's mention of the return payload is valuable, and the parameters are fully covered by the schema. However, for a batch mutation with zero annotations, it omits failure/atomicity semantics and auth requirements an agent would need before committing multiple events.

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

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

Schema description coverage is 100%, so the schema already documents platform, brandId, and the events array with its nested fields; the description adds no syntax or format detail beyond that. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb+resource (create multiple events) and the batch scope via 'Create multiple events at once', which implicitly separates it from the singular sibling loyalteez_create_event. It stops short of explicitly naming that alternative, so differentiation is inferable rather than stated.

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

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

'Perfect for setting up entire programs' gives an implied usage context (bulk/program setup), but there is no explicit when-to-use vs. when-not, nor a pointer to loyalteez_create_event or loyalteez_bulk_events for the single-event or alternative case. Usage is suggested, not specified.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does add some context by explaining that the AI analyzes the app/community and generates implementation code using documentation context, but it omits critical traits like whether the tool writes to the platform, modifies existing data, requires specific permissions, or is purely generative/read-only.

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

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

The core purpose is front-loaded in the first sentence, followed by a useful second sentence about documentation context. The 'See also' link list is somewhat extraneous but not bloated, and the overall length is reasonable for a complex design tool.

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

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

Given the tool's complexity, nested input schema, and absence of both annotations and an output schema, the description is adequate but incomplete. It hints at output content ('optimal event structure, tiers, streaks, and implementation code') and provides documentation links, but does not describe the return format or confirm whether the generated program is persisted or merely suggested.

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

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

Schema description coverage is 100%, so the schema already documents all parameters including nested fields like goals, appType, platforms, budget, audience, and existingEvents. The description adds only 'from context' which minimally references the required context parameter, so baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('Design a complete loyalty program') and differentiates from siblings like loyalteez_create_event by clarifying that it generates event structure, tiers, streaks, and implementation code rather than executing individual event operations. An agent can immediately tell this is a high-level design/generation tool.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives such as loyalteez_create_event or loyalteez_create_events_batch. It only offers context documentation links ('See also') without stating prerequisites or exclusions, leaving the agent to infer appropriate usage.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return payload (custom events, reward amounts, detection methods) and the read-only nature is implied by 'Get', but it says nothing about auth requirements, pagination, rate limits, or error behavior. For an unannotated tool this is adequate but incomplete.

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

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

Two tight sentences with the purpose front-loaded, followed by a brief and useful 'See also' pointer to the REST API docs. Nothing is redundant or padded.

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

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

For a simple read tool with one optional parameter, the description covers purpose, returned content, and usage context. The remaining gaps are output structure detail, pagination, and error handling, which are minor here and partially mitigated by the linked API docs reference.

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

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

There is a single optional parameter (brandId) with 100% schema description coverage, including the LOYALTEEZ_BRAND_ID environment-variable fallback. The description adds no parameter-level detail beyond the schema, which is the expected baseline when the schema already documents everything.

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

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

States a specific verb (Get) and resource (active event configurations for a brand) and enumerates the returned contents: custom events, reward amounts, and detection methods. It is clearly a read/retrieval tool, but it does not name a sibling or otherwise distinguish itself explicitly from tools like loyalteez_calculate_reward or loyalteez_track_event.

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

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

Gives explicit usage context: 'Use this to understand what events are available and how much LTZ each event rewards.' That tells the agent when the tool is the right choice. It stops short of naming alternatives or when-not-to-use cases, so it does not reach a 5.

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

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

No annotations are provided, so the description carries the full burden. The verb 'Get' implies a read-only operation, but the description does not state auth requirements, whether brandId scoping is enforced, any result limits, or return behavior. The doc reference is the only additional context offered.

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

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

Two short sentences that are front-loaded with the core capability, plus a useful documentation pointer. No filler, though it is quite terse relative to the tool's filtering options.

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

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

With no output schema, the description should describe what a ranked leaderboard entry contains, but it does not explain the return shape. The purpose and filtering scope are covered, but return-value context is left to inference.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including the metric options, period enum, limit default, and brandId env fallback. The description adds no parameter syntax or meaning beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get ranked leaderboards') with an explicit scope note ('by any metric'). It does not explicitly differentiate itself from siblings, though 'update_leaderboard_stats' is a clearly distinct write operation, so the read purpose is inferable.

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

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

The description notes supported capabilities ('multiple time periods and platform filtering') but gives no explicit when-to-use guidance, no exclusions, and names no alternative even though a leaderboard-writing sibling exists.

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

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

With no annotations, the description carries the full behavioral burden. 'Get' implies a non-mutating read and the enumerated return fields give useful context, but nothing states whether authentication or brand scoping is required, whether the call is side-effect free, or what happens for an unknown user.

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

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

Two sentences, front-loaded with the core purpose and the return fields, followed by a compact doc reference. Nothing is redundant, though the 'See also' line adds little beyond the schema and could be trimmed.

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

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

There is no output schema, so the description must describe the return payload, and it does so concretely (length, multiplier, next milestone, checked-in-today). Combined with a fully documented input schema, the definition is adequate for calling the tool, though it omits error/empty-state behavior.

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

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

Schema description coverage is 100%, so all three parameters (brandId, streakType, userIdentifier) are already documented with formats and the env-var fallback. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Get) and resource (a user's current streak status) and enumerates the returned facets: streak length, multiplier, next milestone, and today's check-in state. That specificity separates it from sibling writes like loyalteez_streak_checkin or loyalteez_claim_streak_milestone, though no sibling is named explicitly.

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

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

There is no guidance on when to use this read versus alternatives such as loyalteez_get_user_stats, loyalteez_check_eligibility, or loyalteez_streak_checkin. The only pointer is a doc URI, which is a reference rather than a usage condition.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the return content (per-achievement progress plus unlocked flags), which is useful, but says nothing about permissions required for querying another user's data, rate limits, or pagination for users with many achievements.

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

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

One core sentence plus a documentation cross-reference; nothing is wasted and the purpose is front-loaded. The 'See also' line is marginal value but cheap.

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

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

Adequate for a simple two-parameter read, and the description does tell the agent what comes back. With no annotations and no output schema, however, it leaves gaps around error behavior and the achievability of the user-scoped lookup that an agent calling into a loyalty system would want.

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

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

Schema description coverage is 100%, including the accepted userIdentifier formats and the brandId fallback to LOYALTEEZ_BRAND_ID, so the description adds nothing beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource (get all achievements for a user) plus the shape of the result (progress and unlocked status). It does not differentiate from siblings like loyalteez_update_achievement_progress or loyalteez_get_user_stats, which the agent must infer from name alone.

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

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

Usage is only implied: the agent can infer this is the read-side counterpart to loyalteez_update_achievement_progress. There is no explicit when-to-use, when-not, or statement of prerequisites, and the doc link is the only routing aid.

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

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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: balances are stored on-chain, and it provides a concrete fallback (resolve wallet, query the LTZ contract at a specific address via balanceOf() on Soneium Mainnet, Chain ID 1868). It does not address auth requirements or rate limits, but the fallback and on-chain disclosure go well beyond a bare restatement.

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

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

Purpose is front-loaded in the first sentence, followed by usage context and a clearly delimited implementation note. The doc/contract cross-references and numbered fallback are somewhat verbose but each item is actionable rather than filler.

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

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

There is no output schema, so the description carries return-value burden—it names both the balance and recent transaction history, and the historyLimit/includeHistory params are covered by the schema. Combined with the on-chain fallback, an agent has enough to call and interpret this tool correctly.

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

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

Schema description coverage is 100%, so brandId, userEmail, historyLimit, and includeHistory are all documented in the schema itself. The description adds no parameter syntax or format details beyond that, 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.

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

The description states a specific verb ('Get') and resource ('a user's current LTZ balance and recent transaction history'), so the agent knows exactly what it returns. It does not explicitly distinguish itself from related siblings like loyalteez_get_user_stats or loyalteez_get_user_achievements, but the balance-centric scope is clear.

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

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

'Use this to display balance in your app or verify rewards were distributed' gives concrete use cases, and the implementation note routes to loyalteez_resolve_user as a fallback path. It stops short of stating when NOT to use it or comparing against an alternative balance/rewards sibling, so it is strong context without exclusions.

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

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

With no annotations provided, the description carries the disclosure burden. It usefully reveals that stats are aggregated across multiple services and describes a degraded-mode fallback path, which is real behavioral context. It doesn't state auth requirements, rate limits, or whether the aggregation is cached/stale, so it falls short of full transparency.

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

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

Front-loaded with the purpose in the first sentence, then a well-structured implementation note and a docs reference. The enumerated fallback list is genuinely load-bearing, though the 'Platform-specific APIs for activity' line is vague and slightly dilutes the precision of the rest.

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

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

For a read-only aggregation tool with no annotations and no output schema, the description is nearly complete: it names the returned dimensions, the fallback tools, and a doc pointer. It leaves out auth/scope requirements and does not describe response shape, which matters somewhat in the absence of an output schema.

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

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

Schema description coverage is 100%, so the schema already documents brandId, platform, and userIdentifier including the env-var default and the identifier format. The description adds no parameter-level meaning beyond that. Baseline 3 is appropriate when the schema does all the heavy lifting.

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

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

The description states a specific verb ('Get') and resource ('comprehensive stats for a single user') and enumerates the exact dimensions returned: balance, lifetime earnings, streak, activity, and rank. This distinguishes it from narrower siblings like loyalteez_get_user_balance and loyalteez_get_streak_status, which are explicitly named as fallbacks.

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

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

The implementation note tells the agent exactly when to fall back to other tools (when the aggregation endpoint is unavailable) and which tools to call. It does not, however, state the inverse case: that the agent should prefer this tool over assembling the same data manually in normal operation. Clear context, but exclusions aren't spelled out symmetrically.

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

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

With no annotations, the description carries full burden and does disclose the scope of the check (which four backend services are verified), which is valuable. However, it says nothing about authentication needs, rate limits, or whether the check is read-only and side-effect free, leaving meaningful behavioral gaps.

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

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

Three short, front-loaded sentences with no waste; the core purpose leads and the doc reference is a useful trailing pointer.

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

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

No output schema exists, so the description should ideally describe what a health result looks like (per-service status, overall pass/fail), but it does not. For a simple diagnostic tool this is a modest but real gap.

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

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

Schema description coverage is 100% and the single brandId parameter is fully documented in the schema. The description never mentions brandId, so baseline 3 is appropriate since the schema does the work.

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

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

States a specific verb and resource ('Check the health status of Loyalteez APIs') and enumerates what is verified (Event Handler, database, blockchain, Privy). This clearly distinguishes it from the action-oriented siblings like create_event or track_event.

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

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

Explicitly says it is 'Useful for diagnostics and verifying API availability before making calls,' giving a clear usage context. It stops short of naming when-not-to-use or a specific alternative, but no sibling overlaps functionally.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses that this is a read-style 'Get' operation and that the response includes perk details, pricing, and availability, but it omits auth requirements, pagination behavior, rate limits, and whether it is strictly read-only.

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

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

The definition is front-loaded, with the core action in the first sentence and return contents immediately after. The doc link is compact and does not bury the essential information.

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

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

For a read-only list tool with four fully documented parameters, the description gives a useful high-level return summary and points to additional docs. It still lacks output schema detail and does not cover pagination, but the schema and doc reference make it mostly complete.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the input schema. The description adds no parameter-level filtering, default, or formatting semantics beyond what the schema provides, making 3 the appropriate baseline.

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

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

The description states a specific verb and resource: get/list all available perks, with clarifying parenthetical NFT rewards. It distinguishes itself implicitly from redeem_perk and check_perk_eligibility, but it does not explicitly name or contrast with those siblings.

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

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

The description implies usage by saying these are perks users can claim with LTZ balance, suggesting it is a discovery/listing step before claiming. However, it gives no explicit when-to-use guidance, no prerequisites, and no comparison to alternatives like check_perk_eligibility or redeem_perk.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful behavioral traits: activities are subject to daily caps and the call returns reward, progress, and cap status. It omits other important traits for a mutation tool, such as authentication requirements, idempotency, or what happens when the cap is already reached.

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

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

Two tight sentences plus a doc link, with the core purpose and the return shape front-loaded and no wasted prose. The trailing 'See also' is compact and does not pad the definition.

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

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

Because there is no output schema, the description correctly compensates by naming the return fields (reward earned, daily progress, cap status). With no annotations and no sibling differentiation, though, it leaves gaps around permissions, error/cap-exceeded behavior, and how it relates to the other tracking tools.

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

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

Schema description coverage is 100%, so all six parameters are already documented in the schema, including which activity types take count vs durationMinutes. The description adds no syntax or format detail beyond the schema, which is the correct baseline of 3 when the schema does the heavy lifting.

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

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

States a specific verb ('Track') and the resources it applies to (voice time, messages, reactions), which is more than a restatement of the name. However, it does not distinguish itself from the near-identical sibling loyalteez_track_event or loyalteez_process_third_party_event, so an agent cannot route between them from the description alone.

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

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

The description mentions 'daily caps' as a context clue but never states when to use this tool versus loyalteez_track_event or the other event-tracking siblings. The 'See also' pointer to external docs is a reference, not usage guidance, so an agent must infer selection criteria.

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

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

With no annotations, the description carries the full burden. It does disclose the core side effect (a Loyalteez event is created/converted), which is genuine behavioral information, but it says nothing about idempotency, duplicate-message handling, auth requirements, or rate limits for a write-style tool with a rawMessage parsing step.

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

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

Three short, front-loaded fragments: the resource, the transformation, and the use case, plus a docs pointer. No sentence is redundant and nothing buries the key point.

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

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

For a 9-parameter tool with a nested metadata object and no output schema or annotations, the description covers purpose and context but omits what an agent would want next: which parameters are conditionally required per eventType (level vs achievement vs rawMessage) and what happens on parse failure. The docs link partially compensates.

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

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

Schema description coverage is 100%, so the schema already documents all 9 parameters including enums for sourceBot and eventType. The description adds no parameter-level detail (e.g., which params are needed per eventType), so it sits at the baseline.

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

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

The description names a concrete resource and process: handling third-party bot events and converting them into Loyalteez events, with named source bots (Mee6, Arcane, Tatsu). It implicitly distinguishes itself from native-event siblings like loyalteez_create_event, though it never names those siblings explicitly.

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

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

"Use this to integrate with existing Discord leveling bots" gives a clear triggering context that separates it from generic event tools. It stops short of naming alternatives or stating when NOT to use it (e.g., for native Loyalteez events, use loyalteez_create_event).

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

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

With no annotations, the description carries the full burden and does disclose key traits: it is a mutation, it writes a redemption record, it returns a confirmation code, and it has an out-of-band precondition (separate LTZ deduction). It omits idempotency, permission/auth requirements, failure modes, and whether redemption is reversible, which matters for a write tool with zero annotation coverage.

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

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

Three short sentences, front-loaded with the action and outcome, then the critical caveat, then a reference link. Every sentence earns its place with no filler.

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

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

The description supplies the essential operational caveat about separately deducting LTZ, which is the most likely agent error, but a mutation tool with no annotations and no output schema would benefit from stating auth/permission needs, idempotency behavior, and error conditions.

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

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

Schema description coverage is 100%, so all four parameters are already documented, including the brandId env-var fallback and the userIdentifier format. The description adds no parameter-level syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('Redeem a perk for a user') and goes further by naming the side effects (creates a redemption record, returns a confirmation code). This clearly distinguishes it from siblings like loyalteez_check_perk_eligibility, loyalteez_list_perks, and loyalteez_claim_drop.

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

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

The note that LTZ must be deducted separately gives real workflow context — an agent knows redemption alone does not debit the balance — and the doc link points to further guidance. It stops short of 5 because it names no alternative sibling or explicit when-not-to-use condition.

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

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

With no annotations, the description carries the full burden, and it does surface two important traits: the transaction is gasless (no ETH required) and it needs Privy auth. For an on-chain state mutation it omits critical behavior: irreversibility/settlement, failure handling, and submission/confirmation semantics, so the disclosure is partial.

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

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

Front-loads the core action ('Execute a gasless blockchain transaction') in the first sentence, then adds use cases and the auth requirement, plus a doc pointer. Efficient with little waste, though the use-case list is slightly redundant with the following clause.

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

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

The tool is a complex, high-stakes transaction executor with a nested permit object and no output schema, so the description should say more about what is returned (e.g., a transaction hash or status) and how failures surface. It covers purpose, auth, and a docs link but leaves return/failure behavior unaddressed.

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

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

Schema description coverage is 100%, so the enum on 'to', the permit object, gasLimit, and the token parameters are already documented in the schema. The description adds the 'gasless' framing but no parameter syntax or constraints beyond what the schema provides, matching the baseline of 3.

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

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

States a specific verb and resource ('Execute a gasless blockchain transaction') and enumerates concrete use cases (claim perks, transfer LTZ, contract interaction), so the agent understands what it does. However, it does not name or distinguish itself from related siblings like loyalteez_claim_drop or loyalteez_redeem_perk, which may be the intended path for the perk-claim case.

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

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

The use cases imply when the tool applies and 'Requires Privy authentication' flags a precondition. But there is no explicit when-not guidance and no named alternative, so an agent cannot tell when to call this relayer directly versus the higher-level siblings such as loyalteez_redeem_perk.

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

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

With no annotations, the description carries the full burden, and it does disclose two meaningful traits: wallet creation as a side effect and a deterministic email mapping ({platform}_{userId}@loyalteez.app), which implies idempotent retries. However, it says nothing about required auth/permissions, rate limits, or what happens on conflict or invalid platform IDs.

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

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

Three short lines, front-loaded with the core operation and the side effect, then the mapping rule, then a reference link. No filler sentences and nothing that could be cut without losing meaning.

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

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

For a 4-parameter tool with no output schema and no annotations, the description covers the operation and side effect but omits the return shape (presumably a wallet address) and error/edge behavior. An agent can call it correctly but cannot anticipate the response, which is a real gap when no output schema exists.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value beyond the schema by explaining how platform and platformUserId are combined into a deterministic identity. It does not explain brandId or platformUsername semantics, so it only partially extends the schema.

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

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

The description states a specific verb and resource ('Convert any platform identity to a Loyalteez wallet') and immediately adds the side effect ('Creates wallet if needed'). No sibling tool in the list performs identity-to-wallet resolution, so the agent can distinguish it without opening the schema.

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

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

Usage is implied by 'Convert any platform identity to a Loyalteez wallet', but there is no explicit when-to-use/when-not-to-use and no named alternative among the many siblings (e.g. get_user_balance, get_user_stats) that also take a user reference. The 'See also' pointer is a doc link, not usage guidance.

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

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

No annotations exist, so the description carries the full burden. It discloses side-effect-relevant behavior ('applies bonus multipliers', tracks consecutive daily activity), which is meaningful. However, it omits idempotency (does a second check-in compound?), error behavior, and what happens on a missed day, which matters for a mutation-style tool.

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

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

Two sentences plus a docs pointer, front-loaded with the operation and its effect. Efficient, though the second sentence is somewhat redundant with the first.

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

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

For a 3-param tool with no annotations and no output schema, the description tells the agent what the call does but not what it returns (new streak count? multipliers applied?) or the streak semantics. The docs link partially compensates, leaving it adequate but incomplete.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (userId, brandId, platform) including their formats and env fallback. The description adds no parameter-level semantics beyond what the schema provides; baseline 3 is correct.

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

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

States a specific verb and resource ('Process a streak check-in') and clarifies the mechanism (automatic multipliers and milestones). It does not explicitly distinguish itself from the sibling 'loyalteez_log_activity' or 'loyalteez_get_streak_status', leaving the agent to infer the boundary, which keeps it from a 5.

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

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

No when-to-use guidance is given. The description does not say when to prefer this over log_activity or check_status, nor does it state preconditions. The only pointer is a docs URI, which is not actionable routing.

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

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

With no annotations, the description carries the full burden, and it does disclose the backend pipeline: auth via brandId, eligibility check, then reward issued from balance — useful side-effect and prerequisite context. It stops short of idempotency, duplicate-event handling, failure modes, or rate limits, which matter for an event-firing tool that can move rewards.

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

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

Very short and front-loaded, with the pipeline summary compactly conveyed. "Works for ANY event type" slightly restates "Fire any event," but the see-also pointer to the REST docs is a useful, low-cost addition.

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

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

For a 7-parameter tool with a nested object and no output schema, the description covers the auth/eligibility/reward flow but says nothing about what a successful call returns, what errors look like, or whether repeated events double-reward. Adequate but with clear gaps for a mutation-adjacent tool.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters including the nested userIdentifier object, making the baseline 3 appropriate. The description adds only that brandId is used for the auth step, which is marginal beyond what the schema states.

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

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

"Fire any event" names a resource (event) but the verb "fire" is informal and vague, and the description never distinguishes this from close siblings like loyalteez_create_event, loyalteez_log_activity, or loyalteez_process_third_party_event. The "ANY event type - predefined or custom" clause broadens scope but doesn't clarify the tool's distinct purpose.

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

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

It implies usage by stating the tool accepts any event type, predefined or custom, which tells an agent the applicability is broad. However, it gives no when-to-use vs. when-not guidance and names no alternative, so an agent choosing between this and the other event-writing siblings must guess.

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

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

No annotations, so description carries full burden. It discloses the automatic unlock behavior and that unlocked achievements are returned, which is useful. But it omits permission requirements, whether updates are idempotent, side effects beyond unlock, and error behavior for a mutation tool.

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

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

Two tight sentences plus a reference link; front-loaded with the core action and outcome. No filler.

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

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

For a mutation tool with no annotations, no output schema, and six parameters, the description covers the core behavior (progress update, auto-unlock, returned unlocks) but lacks necessary detail on permissions, idempotency, and error handling to be fully complete.

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

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

Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional parameter meaning, such as increment semantics or brandId fallback behavior, leaving baseline 3 appropriate.

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

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

States a specific verb (update) and resource (achievement progress) with a clear outcome: automatic unlock at threshold and returned unlocked achievements. Distinguished from siblings like loyalteez_get_user_achievements (read) and loyalteez_log_activity by focusing on progress mutation.

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

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

Clear implied context of updating progress, but no explicit when-to-use versus alternatives like track_event or log_activity, which might also drive achievement progress. The 'See also' doc link points elsewhere but doesn't route between tools.

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

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

With no annotations, the description carries the full disclosure burden. It adds ordering semantics (must run after reward distribution) and the effect on leaderboard currency, but is silent on idempotency, whether stats are additive, required permissions, and failure behavior for a mutation tool.

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

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

Three short sentences plus a doc link, all front-loaded with the action first and the timing constraint second. No filler or repetition.

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

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

The doc resource reference partially compensates, but for a write tool with no annotations and no output schema, an agent still lacks idempotency, permission, and failure-mode guidance needed to call it safely in automated reward flows.

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

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

Schema description coverage is 100%, so all six parameters are already documented in the schema, and the description adds no parameter-level meaning beyond what is there. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Update user statistics') and ties it to a concrete outcome ('keeps leaderboard data current'). An agent can distinguish it from the read-side sibling get_leaderboard, though it doesn't explicitly differentiate itself from other update/write siblings like update_achievement_progress or track_event.

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

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

'Call after every reward distribution' gives an explicit trigger condition tied to a sibling activity (rewarding). It clearly says when to invoke, but offers no alternatives or exclusions for the case where another update tool might be the right choice.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the algorithm (HMAC-SHA256) and that signatures come from the X-Loyalteez-Signature header, but it never states what the tool returns on success/failure or how a validation error surfaces.

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

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

Purpose is front-loaded, the crypto detail and security rationale follow, and a doc reference closes it. Four short lines with no padding.

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

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

For a mutation-free validator with no annotations and no output schema, the definition covers intent, algorithm, and the header source but omits return semantics (boolean vs. error) and any failure-handling guidance an agent would need to act on the result.

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

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

Schema coverage is 100% and the three parameter descriptions (secret, raw payload, signature header) are self-explanatory, so the schema does the heavy lifting. The description adds no parameter-level syntax or format detail beyond it.

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

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

States a specific verb+resource ('Validate a webhook signature') and adds the goal ('ensure the request is from Loyalteez'). No sibling performs validation, so the tool is inherently distinct from the event/reward tools listed.

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

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

Gives a clear when-to-use ('verify webhook authenticity before processing events') and a security directive ('always verify signatures'). It does not name alternatives or explicit exclusions, but none are needed for a standalone validator; the docs link is a helpful pointer.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the returned code includes signature verification, error handling, and event processing, but it does not state whether the tool has side effects, requires authentication, or is rate-limited. The output-content description is helpful but incomplete for a no-annotation tool.

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

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

The description is short and front-loaded, with purpose first, then output, then supported frameworks, then a link. There is minor redundancy between the first two sentences (both say it returns ready-to-use code), but overall it is efficient.

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

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

With no annotations and no output schema, the description does well to explain what the tool returns (code with signature verification, error handling, and event processing) and which frameworks are supported. It could be more complete by clarifying side-effect expectations, but it covers the essential operational context for a code-generation tool.

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

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

Schema description coverage is 100%, so the schema already documents both parameters and their meanings. The description adds a mapping between friendly framework names (e.g., Node.js/Express) and enum values, but it does not mention the endpoint parameter or add syntax/format details beyond the schema.

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

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

The first sentence states a specific verb and resource: 'Generate complete webhook receiver code for your framework.' It clearly distinguishes the tool from webhook processing siblings like validate_webhook, but it does not explicitly name or rule out any sibling, so it falls short of the top score.

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

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

The purpose implies when to use it (when you need ready-to-use receiver code for a given framework), but there is no explicit when-to-use statement, no exclusions, and no named alternatives. The 'See also' link is supplementary, not routing guidance.

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