Resonance Reward Agent

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals search, ranking, and personalization behavior, but does not mention return format, edge cases, or whether the operation is read-only. This is moderate transparency but leaves some 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?

The description is two sentences, front-loaded with the core purpose. No redundant or irrelevant information. Every sentence contributes meaningful detail.

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

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

Despite lacking an output schema and annotations, the description adequately covers what the tool does, when to use it, and key behavioral aspects. The missing return format is a minor gap, but the description is sufficient for an agent to select and invoke the 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?

The schema covers all 5 parameters with descriptions, so the baseline is 3. The description adds value by explaining the overall algorithm (ranks by reward value, personalizes with user balances) and how intent and category interact, providing context beyond the schema.

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

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

The description clearly states the tool's action and resource: 'Find the best cashback deals and rewards matching a shopping intent.' It also describes specific behaviors (searches by category, ranks by reward value, personalizes based on user balances) that distinguish it from sibling tools like browse_perks or compare_cashback.

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

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

The description provides an explicit usage context: 'Use this when a user wants to shop, eat, travel, or game and wants the best rewards.' This gives clear guidance on when to use the tool, though it does not explicitly mention alternatives or 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?

No annotations are provided, so the description carries the transparency burden. It discloses the types of metrics returned, but does not clarify whether the operation is read-only, describe the output format, or mention any side effects. For an analytics tool this is a partial disclosure.

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 two sentences long, front-loaded with the core purpose, and every clause adds relevant detail. No filler or redundant 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?

With no output schema and no annotations, the description should explain enough about what the agent will receive. It lists metric categories but does not describe the response shape, the meaning of 'daily performance trends' in terms of data, or how this tool relates to similar brand-level tools like brand_health. Gaps remain.

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 both brandId and period are documented. The description adds little beyond the schema—it implies the brand and time period but does not elaborate on parameter syntax or behavior. Baseline 3 is appropriate since the schema already provides the needed semantics.

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

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

The description clearly identifies the tool as providing 'deep analytics for a specific brand' and lists specific metrics (daily performance trends, customer velocity, event activity, program health metrics). It distinguishes from general brand info tools, though it lacks an explicit verb like 'get' or 'analyze', making it slightly less directive.

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 includes a clear use case: 'Use this to understand how a brand's reward program is performing.' It does not explicitly mention alternatives or when not to use the tool, but the use case provides adequate context for a sibling-rich environment.

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 full burden. The 'Get' verb implies a read-only operation, and the description specifies the returned data types. However, it does not disclose any behavioral constraints (e.g., required permissions, data freshness, or limitations). This is adequate but not rich.

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?

A single, front-loaded sentence with a colon and a clear list of output components. Every word earns its place, no repetition or filler. Excellent structure.

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 must explain return values, and it does: archetype breakdown, engagement levels, platform split, and drift over time. It does not specify exact schema or time range, but for a single-parameter tool this is sufficiently complete.

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

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

Schema description coverage is 100% (brandId described as 'The brand identifier'), so baseline is 3. The tool description adds no additional parameter semantics beyond implying the brand context, which is already clear from the schema. No extra value is added.

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

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

The description uses a specific verb 'Get' and a clear resource 'a brand's user persona distribution', and enumerates distinct output components (archetype breakdown, engagement levels, platform split, archetype drift). This clearly differentiates it from sibling tools like brand_analytics or perk_audience.

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

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

The description provides clear context for when to use this tool: whenever a brand's user persona distribution is needed. It does not explicitly mention alternatives or exclusions, but the phrasing 'Get a brand's...' makes the use case obvious, so it earns a 4 rather than 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 of behavioral disclosure. It explains that the tool 'analyzes event performance, perk utilization, and customer engagement' and 'suggests optimizations,' which gives a sense of the internal logic. However, it does not state whether the operation is read-only, whether special permissions are needed, or what the return structure looks like, leaving some 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?

The description is two sentences, front-loaded with the primary purpose and followed by a concise list of analysis areas. Every sentence contributes value, with no filler or redundancy.

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

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

For a tool with one parameter, no output schema, and no annotations, the description is reasonably complete. It conveys what the tool does, the key analysis areas, and the nature of the output (data-driven recommendations). It could be improved by explicitly mentioning the return type (e.g., a report or score), but the current level covers the essentials.

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

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

The schema covers 100% of the single parameter brandId with a simple description, so the parameter is already well documented. The description adds no additional meaning about brandId beyond what the schema provides, warranting the baseline score 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?

The description clearly states the tool's function: 'Get a program health assessment for a brand with data-driven recommendations.' It specifies the resource (brand health) and the output (recommendations), and the second sentence enumerates the analysis dimensions (event performance, perk utilization, customer engagement), distinguishing it from sibling brand tools like brand_analytics or brand_info.

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 when to use the tool (when a brand health assessment with recommendations is needed), but it does not explicitly state when NOT to use it or name alternatives. Sibling tools exist, but no guidance is given on how this differs from brand_analytics or brand_rankings, leaving some ambiguity.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It accurately describes the kind of data returned (actions, rates, bonuses) but doesn't explicitly state that the operation is read-only, what happens if the brand is not found, or any limitations. The description is honest but lacks explicit safety or side-effect details.

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 a single, well-structured sentence that front-loads the core purpose and then enumerates specifics. It contains no redundant phrases, making it efficient and easy to parse.

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

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

The tool is simple (one parameter, no output schema), and the description covers the main aspects of what the tool returns. It doesn't detail error scenarios or response format, but for a straightforward getter, the provided info is largely sufficient. A slightly longer mention of return structure would push it to a 5.

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

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

Schema coverage is 100% with brandId described as 'The brand identifier. Use rsnc_agent_list_brands to discover brands by category.' The description adds context about what the tool returns but doesn't elaborate on the parameter itself beyond the schema, so the schema already does the heavy lifting. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Get details on a brand's reward program' and specifies exactly what those details include (earning actions, cashback amounts, bonuses). This distinguishes it from sibling tools like brand_analytics, brand_health, and brand_perks, which focus on different aspects.

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 the tool is for retrieving reward program details, but it doesn't explicitly compare it to alternatives or state when to prefer this over siblings like brand_perks or compare_brands. The only additional guidance is in the schema hint to use rsnc_agent_list_brands for discovering brands, which addresses how to find the brandId, not when to use this tool.

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

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

With no annotations, the description must carry the burden of behavioral disclosure. It reveals that the output includes redeemability and cost, but does not explicitly confirm read-only behavior, mention permissions, pagination, or side effects. The verb 'browse' suggests non-mutating, but this is implicit rather than explicit.

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

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

The description is two sentences, front-loaded with the verb 'browse', and provides useful examples. Every word earns its place with no redundancy or fluff.

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

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

For a simple read-only tool with a complete input schema and no output schema, the description gives the essential information: what it does and what the user can learn (redeemability, cost). It lacks an explicit return format but is still adequate for a tool of this simplicity.

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

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

Schema coverage is 100% — both parameters have descriptions (brandId points to list_brands; category is an optional filter). The description adds no new parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the verb 'browse' and resource 'a brand's available rewards', with examples (discounts, free products, etc.) and what info is shown (redeemability, cost). It does not explicitly distinguish from the similar sibling 'rsnc_agent_browse_perks', which may be a generic perk browsing tool, so it loses 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 description implies usage for exploring a brand's rewards but does not explicitly state when to use this tool over alternatives like rsnc_agent_browse_perks or claim_reward. A prerequisite hint (use rsnc_agent_list_brands) exists in the schema but not in the description, leaving the guidance implicit.

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 full burden. It mentions ranking by rewards, active programs, or cashback rates, but does not explain how these criteria are selected or combined, given that the schema has no metric parameter. It also does not disclose whether the operation is read-only, what the output looks like, or any other behavioral details.

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 brief (two sentences) and front-loaded with the action. It is free of fluff, though the second sentence restates the value proposition of the first. Overall, it is well-structured and easy to scan.

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

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

The tool has no output schema and no annotations, so the description should explain return values and behavior. It does not describe the output format, and the ambiguity about how the ranking criteria work leaves a significant gap. The description is adequate for a basic sense of purpose but incomplete for an agent to confidently invoke the tool without expecting surprises.

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

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

Schema coverage is 100%, with both parameters (limit and category) having descriptions. The tool description adds no parameter-specific detail beyond this. Since the schema already provides full coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: viewing brands with the most rewards, active programs, or best cashback rates. The verb 'see' is a bit weak, but the resource (brands) and ranking context are clear. It distinguishes from some siblings like 'best_deals' but does not explicitly differentiate from 'leaderboard' or 'compare_brands'.

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

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

The description explicitly provides a use case: finding where to shop for maximum value. This gives clear context for when to use the tool. However, it does not mention any exclusions or alternatives, such as using 'compare_brands' for head-to-head comparisons or 'best_deals' for finding deals.

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

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

With no annotations provided, the description carries the full burden of explaining behavior. It conveys a read-only search action without mentioning side effects, authorization, or return format. The lack of explicit non-destructive confirmation or pagination details is a slight gap, but the language 'search' and 'find' strongly implies a safe, read-only operation.

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

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

The description is a single, front-loaded sentence that efficiently communicates both the main action and key filters. No redundant words or filler; it earns its place entirely.

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 has four optional parameters, no output schema, and no annotations. The description gives a good high-level overview but does not mention what the result set looks like, whether pagination is supported (though 'limit' hints at it), or how results are ordered. For a read-only search tool, this is adequate but leaves some room for improvement.

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

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

The schema already describes all four parameters with 100% coverage, so the description adds little new meaning. It does reinforce 'category' and 'budget' (mapping to category and maxPrice), but does not elaborate on limit or brandId beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: searching for deals, discounts, and rewards across all brands with optional filters by category and budget. It distinguishes itself from sibling tools like rsnc_agent_brand_perks (brand-specific) and rsnc_agent_best_deals (curated picks) by emphasizing broad cross-brand discovery.

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 for browsing or discovering perks, especially when the user wants a broad search rather than brand-specific or targeted deals. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, leaving the guidance somewhat implicit.

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

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

With no annotations, the description must carry the full burden. It discloses the two possible outcomes (reward program details vs. join info), which is useful. Yet it does not explicitly state that the tool is read-only or safe, nor does it mention permissions or side effects, making it minimally transparent.

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 a single sentence that front-loads the purpose and details both outcome branches without any wasted words. It is perfectly sized for a simple lookup 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?

For a tool with one parameter and no output schema, the description adequately covers the tool's function and expected results in both scenarios (found/not found). No critical information is missing for an agent to decide whether to invoke it.

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

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

The schema's sole parameter 'query' already has a thorough description (brand name, domain, or URL with examples), achieving 100% coverage. The tool description adds no further parameter semantics, so the baseline score 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 uses a specific verb ('Check') and resource ('brand or website on the Resonance cashback network'), clearly indicating the tool's function. It distinguishes itself from siblings like brand_info or list_brands by focusing on membership status and join information, which is a unique 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?

The description provides clear context for when to use the tool: to check if a brand/website is on the network. However, it does not explicitly name alternative tools or exclusion scenarios, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the burden. It discloses that rewards are paid from the Resonance network fund and subject to daily and weekly rate caps, which is important behavioral context. It also specifies exact reward amounts per action type. However, it does not mention potential failure cases, idempotency, or prerequisites beyond the schema parameters.

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 three sentences with no filler. The lead sentence states the purpose immediately, followed by key facts about funding and reward amounts. This is concise and well-structured.

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

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

The tool is simple (2 required params, no output schema). The description covers the core behavior, reward amounts, and rate caps, making it usable without additional explanation. The lack of output schema is mitigated by the straightforward nature of a claim action, though details about return values are not specified.

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

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

The schema already covers both parameters with 100% description coverage, so baseline is 3. The description adds meaningful context by mapping rewardType values to specific amounts ('Discovery earns 100 RSNC, onboarding earns 500 RSNC'), going beyond the enum labels. It does not add additional meaning for brandAddress beyond what the schema states, but the overall value justifies a 4.

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

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

The description clearly states the tool's function: 'Claim a reward for a valuable agent action.' It specifies reward types and amounts ('Discovery earns 100 RSNC, onboarding earns 500 RSNC'), distinguishing it from read-only sibling tools like rsnc_agent_my_rewards and action tools like rsnc_agent_redeem_perk. This makes it easy for an agent to identify this as the reward-claiming 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 implies the correct usage: use this tool after performing a discovery or onboarding action to claim a RSNC reward. It provides context about reward amounts and rate caps but does not explicitly mention alternatives or exclusions (e.g., when to use my_rewards instead). Thus it gives clear usage context without explicit when-not-to-use guidance.

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

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

With no annotations, the description carries the transparency burden. It explicitly states the return format ('structured comparison matrix with per-metric winners and insights'), which is useful. However, it does not disclose potential limitations like data freshness, permissions, or that it is a read-only operation, though 'Compare' implies safety.

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: the first states purpose and scope, the second describes the output. No unnecessary words, front-loaded with the primary action.

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 has only 2 parameters (fully described in schema), no output schema, and moderate complexity. The description adequately covers output structure and metrics, making it sufficient for an agent to select and invoke the tool. Missing minor details like period default, but that is in 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 coverage is 100%, so baseline is 3. The description adds meaning by naming the specific metrics compared (velocity, customers reached, transactions, etc.), which goes beyond the schema's generic parameter descriptions and helps the agent understand the tool's scope.

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

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

The description uses a specific verb ('Compare') with a clear resource ('brands'), specifies the count range (2-5), and enumerates the performance metrics covered. This clearly distinguishes it from sibling tools like compare_cashback, which is narrower in scope.

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

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

The description implies usage by listing comprehensive brand performance metrics, making it clear when to use this instead of a single-brand analytics tool or a cashback-only comparison. However, it does not explicitly name alternatives or state when not to use it.

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

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

With no annotations, the description must disclose behavioral traits. It does state the tool 'Shows exactly how much you earn' and gives an output example, which is behaviorally transparent. However, it does not explicitly state that this is a read-only operation or mention any side effects, which would be valuable given the lack of annotations.

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 two sentences long, front-loaded with the main function, and includes a helpful example. Every word earns its place with no filler or redundancy.

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

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

The tool is simple with 3 params and no output schema, and the description plus schema cover the main functionality. The example clarifies the output format. It could mention edge cases like what happens when no brands match, but overall it's sufficient for an agent to select and invoke correctly.

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

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

The schema already describes all 3 parameters with 100% coverage, including that brandIds can be omitted to use category auto-discovery. The description adds marginal value by reinforcing the purchase amount context but doesn't offer new parameter semantics beyond the schema. 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 uses the specific verb 'Compare' and resource 'cashback rates across brands' for a specific purchase amount. It provides a concrete example ('Buy $100 at Nike = $8 back vs Adidas = $3 back') that clearly distinguishes it from siblings like compare_brands, which likely compare other metrics. This is a clear, specific 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?

The description explicitly positions this as 'The key decision tool for purchase routing,' implying when to use it for purchase decisions. It does not explicitly mention alternatives or exclusions, but the use case is clear from the example. The phrase 'for a specific purchase amount' narrows the context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds one notable behavior: 'The agent validates the configuration against the brand's data maturity before creating.' However, it does not disclose side effects, permissions, or failure behavior, which is a gap for a mutating 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 two sentences and 30 words, with the primary action front-loaded. Every sentence earns its place: the first states what the tool does, the second provides domain context and a behavioral detail. No wasted words.

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?

Without annotations or an output schema, the description is moderately complete. It covers the core purpose and a validation behavior, but lacks explicit guidance on return values, prerequisites, or failure conditions. The 100% schema coverage compensates for parameter details, but the overall contextual picture is incomplete for an agent seeking to invoke the tool safely.

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

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

Schema description coverage is 100%, and each parameter is fully described in the input schema. The description does not add any parameter-specific context beyond the schema, so it meets the baseline but does not exceed 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?

The description clearly states the action ('Create a new reward event') and identifies the domain ('for a brand'), and explains what events represent ('user actions earn cashback'). This is specific, distinct from sibling tools like rsnc_agent_update_event and rsnc_agent_process_event, and conveys the tool's purpose in a single, direct sentence.

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

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

The description provides clear context for when to use this tool—when creating a new reward event—but does not explicitly mention alternatives or exclusions. The distinction from update_event is implied by the name, but the description could be stronger by explicitly saying 'use this to create, update_event to modify' or noting when not to use it.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states 'create' but does not disclose side effects, authorization requirements, reversibility, or return behavior. For a mutation tool, this lack of detail is a significant gap.

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

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

The description is two sentences, front-loaded with the primary action, and includes a clear explanation of the domain. Every sentence adds value without unnecessary verbosity.

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 has 8 parameters, no output schema, and no annotations. The description explains the purpose and perk concept but does not mention return values, error conditions, or side effects. While the schema covers parameters well, the absence of behavioral context for a creation action leaves some 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 fully documents each parameter. The description adds conceptual context by explaining what perks are (rewards claimable with RSNC tokens), but it does not add syntax or format details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Create a new perk collection for a brand.' It uses a specific verb ('create') and resource ('perk collection for a brand'), and explains what perks are. This distinguishes it from siblings like update_perk, browse_perks, and 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 usage by stating what it does, but it does not explicitly mention when to use this tool over alternatives such as update_perk or suggest_perks. The context is clear enough for a simple creation action, but it lacks explicit exclusions or alternative guidance.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It states the tool 'projects engagement and retention impact,' which gives some insight into its computation, but it doesn't disclose limitations, assumptions, or what exactly happens with missing inputs. It adds modest context beyond the schema but is not rich in behavioral detail.

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 with no wasted words. The first sentence states the core purpose, and the second explains what it takes and what it projects. Well-structured and front-loaded.

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

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

The tool has no output schema, and the description does not mention the format of the ROI estimate (e.g., a number, a report, a percentage). For a tool that returns a projection, this is a notable gap. However, the tool's complexity is low and the purpose is clear enough for basic use.

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

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

The schema already covers 100% of the parameters with descriptions, so the baseline is 3. The description adds that inputs are 'industry and business metrics' but the schema already says 'Estimated monthly customers' and 'Average transaction value.' No additional syntax or format details are provided.

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

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

The description uses a specific verb 'Estimate' and clearly identifies the resource: 'return on investment of adding a Resonance cashback program.' This is distinct from the many sibling tools related to analytics, perks, or brand health, so purpose clarity is high.

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 clearly implies when to use this tool: whenever an ROI estimate for a Resonance cashback program is needed. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to select this tool over others.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, any side effects, data freshness, or limitations. The phrase 'See how' implies observation but does not explicitly confirm non-mutating behavior or other constraints.

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 a single, well-structured sentence that is front-loaded with the core purpose and lists key metrics. Every word adds value; there is no redundancy or 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?

Given the lack of output schema and annotations, the description provides a general sense of the returned data (engagement, claim rates, reward efficiency) but lacks specifics such as return format, filtering options, or what 'per event type' means in practice. It is adequate but leaves room for ambiguity.

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

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

The input schema has full coverage (100%) with descriptions for both brandId and period. The tool description adds no additional parameter semantics beyond what the schema already provides, but it does give context on the metrics returned, which is not directly about 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?

The description clearly states the tool's purpose: to see reward event performance at a brand, including engagement, claim rates, and reward efficiency. It uses a specific verb ('See how') and resource ('each reward event') that distinguishes it from sibling analytics tools like perk_analytics or brand_analytics.

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 guidance is provided on when to use this tool over alternatives. The description does not mention prerequisites, exclusions, or alternative tools, leaving the agent to infer usage solely from the purpose.

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 full responsibility for disclosing behavioral traits. It does not mention whether this is a read-only operation, what data it returns, default sorting, or any side effects. It only describes purpose, not behavior, leaving the agent without insight into how the leaderboard is generated or what to expect besides 'top earners.'

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 concise sentences, front-loaded with the primary action, and no redundant filler. Every word contributes value, making it efficient and well-structured.

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?

This is a simple listing tool with four parameters and no output schema. The description covers the core purpose and typical use cases. It does not explicitly state the return format, but for a leaderboard tool this is likely clear. Given the simplicity, the description is reasonably complete, though it could mention that it returns a ranked list.

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 already well-documented. The description adds minimal extra meaning: 'top earners' hints at the rsnc_earned metric, and 'most active customers' hints at activity, but the schema already lists these enum values with descriptions. The description does not significantly add beyond the schema.

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

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

The description states a clear purpose: 'See top earners and most active customers for a brand.' This is a specific verb-resource pair (see leaderboard) and includes use cases ('social proof' and 'finding rewarding brands'). However, it does not explicitly distinguish this from sibling tools like rsnc_agent_brand_rankings, so it lacks direct sibling differentiation.

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

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

Provides clear usage context: 'Useful for social proof or finding the most rewarding brands to shop at.' This implies when to use it, but it does not mention any exclusions or alternative tools. The guidance is context-rich but lacks explicit 'when not to use' directions.

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 indicates a read-only action via 'Search and browse', but it does not disclose any additional behavioral traits such as pagination behavior, default ordering, or whether it returns full brand details. It adds no context beyond the schema's limit/offset/category parameters.

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 two sentences long, front-loaded with the primary action and resource, and the second sentence explains the filtering use case. Every word earns its place with no redundancy or filler.

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

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

The tool has no output schema and no annotations, so the description should explain what the agent can expect. It clarifies the purpose and category options but does not describe the return format, default pagination behavior, or how it differs from related tools like brand_rankings or best_deals. This is adequate but leaves notable gaps for an AI agent.

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

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

The schema has 100% coverage with descriptions for all three parameters, including examples for category. The description adds example categories (retail, dining, travel, gaming) similar to the schema's examples, and provides use-case context ('shopping, booking, or purchasing'), but it doesn't add meaningfully beyond what the schema already 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?

The description clearly states the tool searches and browses brands offering cashback, rewards, and deals, and it mentions filtering by category. It distinguishes from sibling tools like brand_info or best_deals by focusing on the brand list itself. However, it doesn't explicitly say 'list' as the verb, so it's clear but not maximally precise.

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 when you want to find relevant offers for shopping, booking, or purchasing, and it mentions category filtering. It does not explicitly name alternatives or exclusions, despite many brand-related siblings existing. The context is present but not strongly differentiated.

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

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

With no annotations provided, the description carries the full burden. It adds valuable behavioral disclosure: 'Never exposes secrets — credentials are accessed through the partner portal.' However, it does not mention side effects of rotate or revoke, permission requirements, or reversibility. The single behavioral note is useful 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?

The description is two short sentences, front-loaded with the main purpose, and every phrase contributes meaning. It avoids empty filler and is highly scannable.

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

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

For a tool with only 2 parameters, no output schema, and no annotations, the description gives essential information: operations, scope, and a security behavior. However, it does not describe the return format or the outcome of each action, which an agent would need to know for status checks or confirming success. It is adequate but not complete.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds a bit of meaning by specifying the action enum values in prose and the brand scope ('brands you onboarded'), but it does not explain the action semantics beyond what the enum labels already imply. The description adds marginal value over the schema.

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

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

The description clearly states the tool's purpose: 'Manage API keys for brands you onboarded.' It specifies the exact operations (rotate, revoke, or check status) and distinguishes itself from sibling tools by focusing on key management. The verb 'manage' is made specific by the listed actions.

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 context by scoping to 'brands you onboarded' and hints the tool never exposes secrets, implying use when key operations are needed. However, it does not explicitly state when to choose this vs. alternatives, nor does it clarify when to use rotate vs. revoke vs. status. No exclusions are provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It uses 'Check' and 'Shows,' implying a read-only operation with no side effects. However, it does not explicitly state read-only status, mention authentication requirements, or clarify whether 'remaining rate cap allowances' refers to the tool's own rate limits or the agent's reward caps. This leaves some ambiguity, though the overall intent is clear.

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

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

The description is concise at two sentences, with the key purpose front-loaded in the first sentence. Every phrase contributes value: it names the specific data areas (earnings, activity stats, rate cap allowances) and then elaborates on reward sources. There is no redundant or filler content.

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

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

For a zero-parameter tool with no output schema, the description is nearly complete. It explains what the tool checks and what information it surfaces, including the types of earnings. It stops short of specifying the exact return format or data structure, but given the low complexity and lack of parameters, the description provides adequate context for an AI agent to understand the tool's function.

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

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

The tool takes zero parameters, and the schema description coverage is effectively 100% (vacuously). The baseline for no parameters is 4, and the description does not need to explain parameter semantics. It simply describes what the tool checks, which is sufficient.

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

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

The description clearly states the tool's purpose with a specific verb and resource: 'Check your agent's RSNC reward earnings, activity stats, and remaining rate cap allowances.' It distinguishes itself from siblings like rsnc_agent_claim_reward and rsnc_agent_user_balance by focusing on agent-specific reward earnings and rate caps, making its role 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?

The description provides clear context for when to use the tool: whenever the agent needs to check reward earnings, activity stats, or rate cap allowances. It does not explicitly exclude alternatives or mention sibling tools, but the context is specific enough that an AI agent would understand when to invoke it, though it could benefit from a note on how it differs from similar reward-related 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 provided, the description carries full burden for behavioral disclosure. It implicitly conveys a read-only operation via 'Get' and notes 'real-time' plus network-wide scope, but it does not state explicit safety (e.g., read-only) or potential caveats like caching or authentication. This is adequate for a simple analytics fetch but not rich.

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 a single, well-structured sentence that front-loads the primary purpose and uses a colon to enumerate what the analytics include. Every word contributes value, with no filler or redundancy.

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

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

The tool is simple (one optional parameter, no output schema or annotations), and the description sufficiently conveys what data it returns. It could be more complete by referencing the period parameter directly or distinguishing from sibling analytics tools, but overall it provides enough context for an agent to invoke it correctly.

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

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

Schema description coverage is 100% for the only parameter (period), including enum and default. The description adds no extra parameter semantics, so the baseline score of 3 applies; the schema already documents all needed details.

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

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

The description clearly states the tool retrieves network analytics, specifying concrete metrics like total users, brands, rewards, and trending categories. It identifies the resource scope (entire Resonance network) but does not explicitly distinguish it from similar sibling tools such as network_trending or network_stats, thus missing a point for differentiation.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or which sibling tools are better suited for particular use cases, leaving the agent to infer its applicability from the general analytics context.

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

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

With no annotations, the description carries the burden of disclosing behavioral traits. It adds context by stating data is anonymous and category-level, and uses 'Shows' implying read-only. However, it does not mention return format, permissions, or rate limits, leaving some ambiguity.

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 extremely concise, two sentences, with the main purpose front-loaded and a parenthetical clarifying key terms. Every word earns its place with no fluff or redundancy.

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

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

For a simple tool with one optional parameter and no output schema, the description is mostly complete. It conveys the core concept and data characteristics, though it could benefit from a brief mention of what the output represents (e.g., category-level flows). Overall, it is sufficient for an agent to select and invoke correctly.

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

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

Schema coverage is 100% with a single parameter 'period' that has a clear enum and description. The tool description does not add additional meaning about the parameter, but the schema already fully documents it, 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 clearly states the tool's function: showing how users flow between brands, with specific concepts (emitters vs attractors). It distinguishes itself from sibling tools by focusing on cross-brand flow rather than individual brand analytics or network-level stats.

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 for analyzing cross-brand user flow but does not explicitly state when to use this tool instead of alternatives like network_analytics or brand_analytics. It provides context but lacks direct comparisons or exclusion 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?

There are no annotations, so the description carries the burden of behavioral disclosure. It only says 'Returns info,' which implies a read-only operation but does not disclose output format, data freshness, or any potential side effects. This adds minimal behavioral context beyond the verb itself.

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?

A single sentence that is front-loaded with the action ('Returns info') and the resource ('Resonance rewards network'). No unnecessary words or repetition; it is efficiently structured.

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

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

For a simple zero-param tool, the description gives useful context about the network's vertical coverage, but it does not clarify what specific 'info' will be returned or how it relates to sibling analytics tools. Since there is no output schema, the description is adequate but somewhat vague.

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

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

The tool has zero parameters, making schema coverage trivially 100%. Per the baseline for 0-param tools, a score of 4 is appropriate since no parameter explanation is needed.

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

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

The description clearly states the tool 'Returns info about the Resonance rewards network' with a scope of 'cross-brand cashback and perks marketplace covering retail, dining, travel, gaming, and more.' However, it does not explicitly differentiate from sibling tools such as network_stats or network_analytics, which also target network-level information.

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 guidance is provided on when to choose this tool over sibling alternatives like network_stats, network_analytics, or network_trending. The description implies general use but does not state exclusions, prerequisites, or alternative 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 burden of explaining behavior. It implies a read-only operation and that it returns counts, but does not define what 'active' means, whether the counts are network-wide or user-specific, or how the output is structured. This is acceptable for a simple stats tool but leaves some ambiguity.

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 a single, front-loaded sentence that states the primary behavior first and then adds practical context. Every word earns its place, with no fluff 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?

For a zero-parameter, no-output-schema tool, the description is largely complete: it explains what is returned and why it is useful. However, it could be more precise about the scope (e.g., whole network) and the meaning of 'active', which would improve completeness.

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

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

The tool has zero parameters and the schema is empty (100% coverage). The description adds value by explaining what the returned counts represent (brands, users, rewards), which is meaningful context beyond the schema. A baseline of 4 for no-parameter tools is appropriate, and the description fulfills this.

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

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

The description clearly states the tool returns counts of active brands, users, and rewards, using a specific verb ('Returns') and a resource ('how many brands, users, and rewards are active'). This distinguishes it from sibling tools like network_analytics or network_info by focusing on aggregate counts and scope.

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

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

The description provides a clear use case: 'useful for understanding the scope of available deals and cashback offers.' This implies when to use the tool (for quick scope assessment), though it does not explicitly mention when not to use it or name alternatives.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. The verb 'See' implies a read-only operation, but the description does not explicitly state that it has no side effects, does not modify data, or mention any auth or rate limiting considerations. It also does not provide any context about the response format or potential limitations of the trending data.

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 a single, well-structured sentence that front-loads the purpose ('See what's trending') and then lists the specific trending elements. Every word is informative and there is no fluff or redundant 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 simple read-only tool with optional parameters and no output schema, the description gives a general sense of the return content (categories and health metrics) but lacks specifics about the data's structure or examples. Given the presence of many similar sibling tools, more context about the exact type of output would improve completeness, but it is minimally viable.

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

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

The input schema covers both parameters (limit and period) with clear descriptions, so the schema itself carries the semantics. The description adds no extra meaning beyond what the schema already provides. With 100% schema description coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states what the tool does: it shows trending content across the Resonance network, including perk categories, brand categories, and network health metrics. The verb 'See' is somewhat passive, but the scope and content of results are specified, which distinguishes it from sibling tools like network_stats or network_analytics, though not explicitly.

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

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

The description provides no guidance on when to use this tool versus alternatives. There are many sibling tools (network_analytics, network_stats, brand_analytics, etc.) that could overlap, but the description does not mention when this trending tool is preferred or when to avoid it. No exclusions or alternatives are given.

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

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

With no annotations, the description carries the burden. It discloses that authentication is required and notes the tool's motivational intent ('creates urgency and drives engagement'). However, it does not explicitly state whether this is a read-only operation or any side effects, though 'Calculate' implies no mutation. The absence of such detail limits transparency.

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

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

The description is three sentences, front-loaded with the core purpose. The final sentence combines 'Creates urgency and drives engagement' with 'Requires authentication,' which is slightly less structured. Overall it is concise and avoids unnecessary verbosity, though the engagement phrase is somewhat marketing-oriented.

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 has no output schema, but the description explains the high-level result (shows number of actions needed). It mentions authentication and optional parameters indirectly through the schema. For a calculation tool, this is sufficient for an agent to select and invoke it, though edge cases or error behaviors are not covered.

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 context about what actions mean (purchases, reviews, referrals) but does not add meaning beyond the schema for userId, brandId, or targetPerkId. The schema already explains those parameters sufficiently.

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

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

The description clearly states the tool's purpose: 'Calculate the fastest path to a user's next attainable reward.' It specifies the verb (calculate), resource (path to reward), and adds details about showing action counts. This distinguishes it from siblings like claim_reward or my_rewards, which focus on different actions.

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 when to use the tool (to motivate users toward a goal) and states a prerequisite (requires authentication). However, it does not explicitly mention alternatives or when not to use it, though the schema notes optional parameters for specific or best goals. This provides clear context but no exclusionary guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the side effects: 'Creates their account, generates credentials (accessible via partner portal), and sends a welcome email.' It also states the permission requirement. This is a solid level of transparency, though it could mention what happens if the brand already exists.

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 three concise sentences, each adding distinct value: the core action, notable side effects, and an access requirement. No filler or repetition. It is front-loaded with the action verb and resource.

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

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

For a tool with 6 parameters, no output schema, and no annotations, the description covers the essential context: what it does, what gets created, how credentials are accessed, and what permission is needed. It lacks details on return values or failure modes, but for an onboarding tool, this is close to 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 parameters already have clear descriptions in the schema. The tool description itself does not add further parameter meaning, such as explaining how fields relate or providing format details beyond what the schema states. 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 begins with a specific verb+resource: 'Register a new brand on the Resonance cashback network.' This clearly distinguishes it from sibling tools, which focus on analytics, perks, or events rather than brand creation.

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

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

The description provides clear context for when to use this tool (registering a new brand) and even specifies a prerequisite: 'Requires agent authentication with onboarding permission.' It does not explicitly name alternatives, but no other sibling tool handles brand onboarding, so the usage context is strong.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only uses the verb 'analyze' which implies read-only, but it does not explicitly state the tool is non-mutating, whether it requires special permissions, or how data is aggregated. The description lacks any caveats about data freshness, scope, or side effects.

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 two sentences, front-loaded with the primary action and specific metrics, and ends with the benefit. Every word earns its place, with no redundancy or fluff.

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 has one parameter, no output schema, and no annotations. The description lists the analyzed areas (redemption rates, supply status, popularity), which gives some indication of the output content, but it does not specify the return format, time range, or any limitations. For an analytics tool, this is a moderate 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?

The input schema has 100% description coverage for brandId ('The brand identifier.'), so the schema already provides full parameter meaning. The description adds no additional parameter context beyond implying the analysis is branded, which does not go beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool analyzes perk collection performance with specific metrics (redemption rates, supply status, popular perks). The verb 'analyze' and resource 'perk collection performance' make the purpose specific. It does not explicitly differentiate from sibling tools like perk_intelligence, but the focus on collection performance is distinct enough.

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 for brands looking to optimize their reward catalog, but it does not explicitly state when to use this tool versus alternatives like brand_analytics or perk_intelligence. No exclusions or alternative tool names are provided, leaving the context to inference.

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

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

No annotations are provided, so the description must carry the behavioral burden. It discloses that the tool is read-only ('Get') and specifies the output dimensions, but it omits access requirements, potential limitations, or response structure. For a simple read tool this is adequate but not comprehensive.

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 a single, well-structured sentence that front-loads the verb 'Get' and immediately states the object and specifics. Every word contributes to understanding, with no filler or redundancy.

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

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

The tool is a straightforward read operation with two well-documented parameters and no output schema. The description explains the purpose and the included dimensions, which is sufficient for an agent to select the tool confidently. A brief mention of output format or data freshness would elevate completeness, so it's a 4.

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

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

The input schema already provides clear descriptions for both parameters (brandId and collectionId), with 100% coverage. The tool description adds no additional parameter-level information, so it remains at the schema-driven 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?

The description uses the specific verb 'Get' and identifies the precise resource: persona breakdown of users who claimed a specific perk. It further enumerates the output categories (archetypes, engagement levels, platform distribution), clearly distinguishing it from sibling tools like brand_audience or user_persona.

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 clearly implies the usage context: when an agent needs audience insights for a specific perk based on claimers. It does not explicitly mention alternative tools or exclusions, but the scope is well-defined and self-explanatory, so it earns a 4.

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 of behavioral disclosure. It indicates the tool returns specific intelligence metrics but does not mention side effects, permissions, data freshness, or whether the operation is read-only (though 'Get' implies it). This is adequate but leaves room for more transparency.

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

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

The description is two sentences, front-loaded with the main verb and resource, and lists useful details without fluff. The second sentence adds a clear purpose. It is appropriately sized with no unnecessary words.

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 simplicity (one parameter, no output schema), the description provides a solid list of returned metrics, which is sufficient. It could benefit from noting the time period or aggregation level, but overall it is reasonably complete for an intelligence-gathering 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?

The input schema has 100% coverage with brandId described as 'The brand identifier.' The description does not add any additional meaning to the parameter, so it scores at the baseline for full schema coverage.

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

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

The description clearly states the tool gets intelligence on a brand's perks and lists specific metrics (heat scores, conversion funnels, supply depletion rates, retention impact), making the purpose clear. However, it does not explicitly distinguish itself from sibling tools like rsnc_agent_perk_analytics, so it earns a 4 rather than 5.

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

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

The phrase 'Helps optimize perk catalogs' implies a use case, but there is no explicit guidance on when to use this tool versus alternatives such as rsnc_agent_perk_analytics or rsnc_agent_brand_analytics. The description provides some context but lacks clear exclusions or alternative recommendations.

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

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

No annotations are present, so the description must carry behavioral disclosure. It mentions 'Requires authentication' which is useful, and 'Record' implies mutation. However, it does not describe partial-failure behavior, validation rules, or return/response format, leaving gaps in transparency for a batch write operation.

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

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

The description is one sentence, front-loads the core purpose with a dash to add authentication context. No fluff; every phrase contributes. It is appropriately sized for the tool's simple parameter structure.

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 has one required parameter, a clear schema, and no output schema. Missing elements include what makes an action 'qualifying', whether partial failures occur, and what the response contains. Given the batch mutation nature and lack of annotations, the description is minimally adequate but leaves important behavioral 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 coverage is 100% — the schema fully describes the events array and its nested properties (userId, brandId, eventType, metadata). The tool description itself adds no parameter semantics beyond the schema, 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?

The description clearly states the tool records multiple qualifying actions in one request, explicitly mentioning batch purchases, signups, or engagement events across brands. This distinguishes it from sibling tools like the single-event rsnc_agent_process_event, satisfying the verb+resource+scope criterion.

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 conveys a batch context ('multiple', 'batch') but does not explicitly state when to use this tool versus the singleton variant or other event tools, nor does it list exclusions. It offers clear context without alternatives, matching the 'clear context, no exclusions' level.

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

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

With no annotations, the description carries the burden. It discloses authentication requirements and the returned reward amount, but does not explain side effects, idempotency, duplicate handling, or failure modes. Some context is provided, but significant behavioral gaps remain.

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 three short, front-loaded sentences. Every sentence adds value: what it does, return value, auth requirement. No redundant or vague wording.

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 has 4 params, a nested object, no output schema, and no annotations. The description covers core purpose and return value, but does not address edge cases, relationship to sibling tools, or expected behavior for non-qualifying actions. 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 parameters are already well-documented. The description adds a list of qualifying event types, but the schema already gives examples. No additional parameter-level meaning beyond the schema.

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

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

The description clearly states the tool's purpose: recording qualifying actions (purchase, signup, review, referral) for cashback, and mentions it returns the reward amount. This distinguishes it from sibling tools like create_event or update_event by emphasizing cashback earning.

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 explicit guidance on when to use this tool versus alternatives like create_event or process_bulk. The description implies use for recording actions, but does not draw boundaries or mention situations where another tool would be preferable.

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

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

With no annotations, the description must fully disclose behavior. It states that authentication is required and that a confirmation code is returned, but it does not explain side effects (e.g., cashback deduction, perk inventory changes), reversibility, or failure modes. For a mutation tool, this is insufficient transparency.

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

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

The description is concise (three short sentences), front-loaded with the main action, and every sentence adds useful information: what it does, what it returns, and a prerequisite. No wasted words.

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 mutation tool with 3 parameters and no output schema, the description covers the core elements: purpose, return value, and authentication. It does not explain broader context like error scenarios or what happens to the user's cashback, but the tool's simplicity and schema completeness mitigate this.

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 parameters are already well-documented. The description adds no additional parameter-specific details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the action: 'Claim a reward for a user — redeem a discount, freebie, or exclusive offer using their earned cashback.' It specifies the resource (perk/reward) and the context (using cashback). However, it does not distinguish from the sibling tool rsnc_agent_claim_reward, which likely overlaps in functionality.

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 when to use the tool (when a user wants to redeem a perk with cashback) and mentions authentication as a prerequisite, but it provides no explicit guidance on when not to use it or which alternative tools to consider. The existence of similar siblings like 'claim_reward' makes this gap notable.

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 burden of behavioral disclosure. It states the tool 'Captures contact details for the partnerships team,' revealing that it stores or transmits information, but it does not disclose side effects such as whether it sends an email, creates a lead record, or requires specific permissions. This adds some context but lacks rich behavioral detail.

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 two sentences, front-loaded with the primary purpose, and every word earns its place. It avoids redundancy and is immediately 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 simple data-capture tool with 100% schema coverage and no output schema, the description is mostly complete. It explains the purpose and what is captured, but it does not mention what the agent should expect as a return value or confirmation. Given the low complexity and clarity of the action, this is a minor gap, so a 4 is appropriate.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds marginal value by framing the parameters as 'contact details' and linking them to the partnerships team, but it does not provide any additional meaning beyond what is already in the schema property descriptions.

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

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

The description clearly states the tool's function: 'Request information about adding a Resonance cashback program to a business.' It uses a specific verb and resource, and the added detail 'Captures contact details for the partnerships team' clarifies the scope. This differentiates it from sibling tools like rsnc_agent_onboard_brand, implying the latter handles actual onboarding while this handles pre-onboarding requests.

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 the use case (requesting info about adding a cashback program) but does not explicitly state when to use it versus alternatives like rsnc_agent_onboard_brand or rsnc_agent_create_event. There are no exclusions or when-not guidance, making the usage guidance merely implied rather than explicit.

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

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

Without annotations, the description carries the full burden. It discloses that the tool compares and ranks brands by cashback, perks, and savings, which is useful. However, it does not clarify whether any side effects occur (e.g., actually executing a purchase) or what the return format is. The word 'route_purchase' could ambiguously suggest transaction execution, but the description's language leans toward decision support 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 description is mostly concise and front-loaded, but the final sentence 'The core purchase intelligence tool for agentic commerce' is promotional and does not earn its place. The first two sentences convey the functional purpose effectively, but the third could be removed without loss.

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

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

For a tool with no output schema and no annotations, the description explains the high-level behavior (comparing and ranking) but fails to specify the exact return structure or whether it actually routes/purchases a product. It leaves some gaps for an agent, but the core purpose is clear enough.

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

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

The schema already provides full descriptions for all four parameters, so baseline is 3. The tool description does not add meaningful semantic detail beyond the schema—it only echoes the concepts of intent and purchase amount. No additional context on parameter usage or syntax is provided.

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

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

The description explicitly states the tool finds the best brand to buy from based on cashback and rewards, then elaborates that it compares all matching brands and ranks them. This is a specific verb+resource+scope and distinguishes it from sibling comparison tools like compare_brands or compare_cashback.

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 a clear usage context: 'Given a shopping intent, compares all matching brands and ranks them.' This implies when to use the tool. However, it does not mention any exclusions or alternative tools, so it lacks explicit when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It explains the calculation logic (base cashback + best redeemable perk + promotions) and implies a read-only operation via 'Calculate'. It does not detail return format or side effects, but the core behavioral context is present.

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 concise and front-loaded: the first sentence states the primary purpose, the second explains the components, and the third gives usage guidance. Every sentence adds value with no redundancy or fluff.

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 calculation tool with three well-documented parameters and no output schema, the description covers the essential aspects: what it does, how it calculates, and when to use it. It lacks explicit return value details but the phrase 'show total savings' implies the output. Given the tool's simplicity, this is sufficiently complete.

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

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

Schema coverage is 100%, and each parameter has a clear description (e.g., userId for checking perks balance). The tool description adds minimal extra meaning beyond the schema, only reinforcing that the calculation is specific to a purchase and brand. Baseline of 3 is appropriate given the schema already documents 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?

The description clearly states the tool's purpose with a specific verb ('Calculate') and resource ('optimal deal stack'), and distinguishes it from siblings by specifying 'for a specific purchase at a specific brand'. It also mentions combining base cashback, redeemable perks, and promotions, which gives a precise scope.

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

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

The description provides explicit usage context: 'Use after route_purchase to maximize value at the chosen brand.' This tells the agent when to invoke the tool relative to other actions. It does not explicitly list when not to use it or name alternative tools, but the contextual guidance is clear.

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 transparency burden. It discloses the analytical basis ('based on network-wide patterns') and implies a read-only recommendation operation via the verb 'Get'. It does not explicitly state side-effect-free behavior or output format, but for a suggestion tool, the transparency is adequate.

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

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

The description is a single sentence that front-loads the core purpose ('Get AI-recommended reward event configurations') and then explains the methodology. Every word earns its place with no redundancy or filler.

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

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

For a tool with only one parameter and no output schema, the description provides sufficient context: it explains what the tool does and how it derives suggestions. It doesn't describe return structure or edge cases, but the simplicity of the tool makes the description complete enough.

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

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

The schema already fully describes brandId ('The brand identifier'), so the baseline is 3. The description adds context that brandId determines the brand's category for network-wide pattern analysis, which enriches the parameter's meaning beyond the schema.

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

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

The description clearly states a specific action ('Get AI-recommended reward event configurations') and a target resource ('for a brand'). It differentiates from sibling tools by focusing on recommendations rather than creating or updating events (rsnc_agent_create_event, rsnc_agent_update_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?

The description provides clear context for when to use the tool: when seeking AI-driven event configuration suggestions based on network-wide patterns. However, it does not explicitly mention alternatives or when not to use it, which would warrant 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. It discloses that suggestions are AI-generated and based on audience and balance patterns, but it does not specify read-only behavior, output format, potential non-determinism, or any side effects. This is a significant gap for an AI recommendation 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 consists of two sentences: the first front-loads the action and resource, and the second adds relevant detail without repetition. Every word earns its place.

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

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

With a single parameter and no output schema, the description explains the instrument's purpose and input basis but does not describe the return value or result format. It is understandable but leaves gaps about what 'perk configurations' look like, which is line with a moderate completeness score.

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

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

The only parameter, brandId, is fully described in the schema with 'The brand identifier,' so schema coverage is 100%. The description adds implicit context by linking brandId to audience composition and balance distribution, but does not add syntax or format details beyond the schema, aligning with 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?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('AI-recommended perk configurations' for a brand). It also details what is suggested (perk types, pricing, supply limits) and the basis (audience composition, balance distribution patterns), distinguishing it from sibling tools like rsnc_agent_brand_perks or rsnc_agent_perk_analytics.

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 when to use the tool (when needing AI-recommended perk configurations) and provides context about the data it uses, but it does not explicitly mention alternatives or when to choose this over related tools like rsnc_agent_brand_perks or rsnc_agent_suggest_events.

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 transparency burden. It does disclose a key behavioral trait: reward amount changes are validated against performance data. This is useful, but it omits other behaviors such as side effects, permission requirements, or what happens if validation fails. The disclosure is partial, not comprehensive.

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 concise sentences, with the first stating purpose and the second adding critical validation behavior. Every sentence earns its place, no fluff or repetition. Front-loaded and 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 output schema and no annotations, the description should explain return values and side effects, but it does not. It does cover a key caveat (validation against performance data), which is helpful. The tool is relatively simple with complete schema coverage, so this is adequate but not fully complete. There is a gap regarding the response format or error behavior when validation fails.

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

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

The input schema has 100% coverage of parameters with clear descriptions, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides. It mentions 'reward amounts' but that maps directly to rewardAmount in the schema, adding no new insight.

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

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

The description clearly states the tool's action: 'Update an existing reward event's configuration.' This is a specific verb+resource that distinguishes it from sibling tools like create_event (create) and update_perk (perk vs. event). The word 'existing' highlights it's for modification, not creation.

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 when modifying an existing reward event, but does not explicitly state when to use this tool versus alternatives. No mention of when not to use it or references to sibling tools like create_event for new events. Guidance is implicit rather than explicit.

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

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

With no annotations, the description must fully disclose behavior. It mentions adjustable fields but omits side effects, permission requirements, reversibility, and what happens to unspecified fields. This is a significant gap 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?

Single sentence, front-loaded with the verb 'Update', and no redundant information. Every phrase earns its place.

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

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

Description covers the core purpose and adjustable fields, but lacks behavioral context such as permissions or side effects. With no output schema and no annotations, this leaves the agent with unanswered questions about consequences of updating.

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 parameters are fully documented. The description adds no meaning beyond the schema; it merely paraphrases some fields (pricing, supply, active status). Baseline 3 is appropriate.

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

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

The description clearly states the tool updates a perk collection's configuration and explicitly lists adjustable aspects (pricing, supply, active status), distinguishing it from create_perk and update_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?

The description provides clear context for when to use (updating existing perk configuration), but does not explicitly exclude alternatives or mention create_perk for new perks. Slight gap but still clear.

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

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

No annotations are provided, so the description carries the full burden. It discloses the authentication requirement and indicates the return values (earned cashback and spendable rewards), which implies a read-only operation. However, it does not explicitly state 'read-only' or mention side effects (e.g., whether it updates anything), nor does it provide error-handling details. This is adequate but not rich.

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 only two sentences, with the primary action front-loaded and no redundant information. Every word contributes to understanding the tool's purpose, scope, and authentication requirement.

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 simplicity (2 required params, no output schema) and the fact that the description already explains the return values, it is mostly complete. However, it lacks any mention of error conditions, default behavior, or limitations (e.g., what if the user has no cashback), which would be useful in edge cases but are not critical for a basic balance check.

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%: both userId and brandId already have clear descriptions. The tool description adds no additional parameter-level meaning beyond what the schema provides, so the baseline score 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 uses the specific verb 'Check' and clearly identifies the resource: a user's cashback earned and spendable reward amount at a specific brand. This scope ('at a specific brand') distinguishes it from more general user-level tools like rsnc_agent_user_stats or rsnc_agent_my_rewards.

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

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

The description provides clear context: it checks per-brand balance and requires authentication. However, it does not explicitly state when to prefer this tool over alternatives (e.g., compare_cashback or my_rewards) or when not to use it, so it earns a 4 rather than 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. It does disclose the HMAC authentication requirement and lists the return categories, which adds context. However, it does not explicitly state whether this is a read-only operation, describe error handling for unknown users, or mention data sensitivity—leaving some behavioral traits undisclosed.

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 a single, well-structured sentence that packs in the purpose, the specific profile components, and the authentication requirement without any filler. Every phrase earns its place.

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

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

With no output schema, the description must convey what the tool returns, and it does so by listing the profile dimensions. It also includes the auth prerequisite. It could be more complete by mentioning error behavior or confirming read-only nature, but it sufficiently covers the essentials for a simple lookup tool.

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

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

Schema coverage is 100% because the only parameter (userId) is described as 'email or wallet address'. The description adds no additional semantic detail about the parameter beyond what the schema already says, so it stays 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 uses a specific verb ('Get') and clearly identifies the resource ('user's behavioral profile'), then enumerates the distinct components (earn patterns, persona archetype, tag/brand affinities, price preferences, network position). This distinguishes it from sibling tools like user_stats and user_balance.

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 clearly implies when to use it: when you need a behavioral profile rather than numerical stats or simple balance. It also notes the HMAC authentication prerequisite. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses the authentication requirement, implies a read-only operation through 'Get' and 'view,' and indicates real-time assessment via 'right now.' While it doesn't explicitly state 'no side effects,' the terminology strongly suggests a safe query, and the listed outputs add useful behavioral context.

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

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

The description is concise and front-loaded with the core action ('Get a unified view...'), followed by concrete output elements and a brief authentication note. Every sentence adds value without fluff or redundancy.

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

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

Despite having no output schema, the description clearly enumerates the key return components (total balance, per-brand breakdown, active streaks, best perk) and the required authentication. For a simple one-parameter query tool, this is complete and sufficient for an agent to invoke 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% for the single userId parameter, which is fully described as 'User identifier (email address or wallet address).' The description does not add any additional parameter information, but the schema already provides complete semantics, 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?

The description clearly states the tool gets a unified view of a user's rewards across all brands, listing specific outputs: total balance, per-brand breakdown, active streaks, and best perk. It distinguishes from siblings by emphasizing 'ALL brands' and the cross-brand dashboard nature, unlike user_balance or user_stats.

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

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

The description provides clear context for when to use this tool: when a cross-brand unified overview is needed, as indicated by 'across ALL brands' and 'cross-brand loyalty dashboard.' It does not explicitly name alternatives or exclusion criteria, but the strong contrast with single-brand tools like user_balance makes the intended use clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses an important security requirement ('Requires HMAC authentication') and explains the recommendation scoring logic ('by persona affinity and affordability'). This goes beyond the basic schema, though it does not detail pagination, error behavior, or return format. For a read-only operation, this is reasonably transparent.

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 two short sentences. The first sentence front-loads the primary purpose with a clear verb and object, and the second sentence adds a critical auth requirement. Every word earns its place, and there is no fluff or redundancy.

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

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

The tool is simple with only two parameters and no output schema. The description covers purpose, scoring methodology, and authentication. It does not explain the output shape, but for a 'recommendations' endpoint that returns a list, this is likely self-evident. Given the low complexity, the description is nearly complete, though it would benefit from a note about what the returned recommendations look like or any default behavior for invalid userIds.

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

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

The input schema already provides 100% coverage with descriptions for both 'limit' and 'userId', so the schema does the heavy lifting. The description does not add any additional meaning about the parameters themselves. Per the calibration rules, the baseline is 3 due to high schema coverage, and the description does not compensate with extra parameter context.

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

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

The description clearly states the tool's function: 'Get personalized perk recommendations for a user, scored by persona affinity and affordability.' This uses a specific verb ('Get'), a resource ('perk recommendations for a user'), and distinguishes it from sibling tools by mentioning personalized scoring criteria. It is not a tautology and clearly indicates the tool's scoped 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?

The description does not explicitly mention when to use this tool versus alternatives, nor does it provide exclusion criteria. The phrase 'for a user' implies the target use case, but there is no guidance on when not to use it or how it compares to sibling tools like rsnc_agent_best_deals or rsnc_agent_suggest_perks. The context is clear but lacks explicit alternatives.

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 transparency burden. It discloses the authentication requirement and outlines the returned data, but does not explicitly state read-only behavior or mention error cases, rate limits, or data freshness.

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 two sentences that front-load the tool's purpose and key details, with no wasted words.

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 adequately covers the necessary context for a simple read tool: what it returns, auth requirement, and use case. Without an output schema, it lists return fields. It lacks alternative guidance but is otherwise 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 the baseline is 3. The tool description does not add further parameter semantics beyond conceptually mapping 'user' and 'brand' to the 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?

The description uses the verb 'Get' and specifies the resource as 'complete reward profile for a brand', listing key components (total earned, total redeemed, active streaks, achievements). This clearly distinguishes it from sibling tools like user_balance or user_recommendations.

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 states it is 'useful for recommending next actions', which gives clear context for when to use this tool. However, it does not explicitly mention alternatives or when not to use it.

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