AgentIQ

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

With no annotations, the description carries the full burden. It discloses that the tool 'returns next tools' and that 'platform support reviews the session', which conveys the output and a side effect (session review). This is helpful, though it does not detail error handling or other potential behaviors.

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 with a short trailing clause, front-loaded with the core action 'Ask MoltAd help when stuck'. Every word earns its place; no verbose or redundant text.

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 relatively simple, but the absence of parameter explanations and an output schema leaves gaps. The description covers the overall purpose and outcome, but not the details needed to correctly populate the parameters, making it only partially 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?

The schema lists four parameters (context, provider, question, stuckState) with 0% description coverage. The description never explains what these parameters mean, how they relate to each other, or how to format the question. The only implicit link is that 'question' is the natural input for asking help, but the others remain opaque.

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: 'Ask MoltAd help when stuck', with a scope covering credits, placements, campaigns, and attribution. It also distinguishes itself by noting it returns 'next tools' and triggers platform support review, setting it apart from action-oriented sibling tools.

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

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

The phrase 'when stuck' provides clear context for when to use this tool, and the mention of specific areas (credits, placements, campaigns, attribution) helps the agent choose it as a fallback. However, it does not explicitly list alternative tools to use instead or exclude cases where a direct action tool is more appropriate.

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, but it does not mention side effects, permissions, costs, or return values. 'Alias' provides no behavioral detail beyond referring to another 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 very short and front-loaded, but it is under-specified rather than efficiently concise. While the one-line alias pointer is compact, it lacks enough substance to be considered appropriately sized.

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 annotations, output schema, and meaningful parameter descriptions, the description is critically incomplete. An agent cannot determine what buying a campaign entails, what inputs are required, or what the tool's behavior is.

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 lists required fields placementId and budgetCredits but no property descriptions. The description adds no parameter semantics, only directing the agent to create_campaign. This does not explain what those fields mean or how to format them.

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 only says 'Alias of create_campaign,' which does not state what the tool does (e.g., purchasing a campaign). It names another tool but lacks a concrete verb and resource description, so the purpose is indirect and not distinguishable.

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

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

There is no guidance about when to use buy_campaign versus alternatives. Merely calling it an alias of create_campaign implies equivalence but does not explain the intended use case, prerequisites, 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.

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

No annotations are provided, so the description must disclose behavior. It reveals that the tool returns a checkoutUrl, requires human approval for Stripe/3DS, and is a shared flow. This gives the agent vital context that it cannot complete the purchase alone.

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

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

Three concise sentences pack purpose, return value, human step, and pack pricing. No fluff; every sentence adds 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 one-parameter tool with no output schema, the description fully covers purpose, return, required user action, and pack pricing. 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?

The schema already documents packId with enum descriptions (starter, builder, fleet). The description adds further meaning by mapping each pack to credit amounts and prices (starter 500/$5, etc.) and the credit peg (100 credits = $1), exceeding schema coverage.

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

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

The description opens with a clear verb+resource: 'Buy MoltAd credits via Stripe Checkout.' It distinguishes from sibling tools like buy_campaign/buy_placement by specifying it funds the wallet for ad spend or payouts.

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?

States the intended use ('fund wallet for ad spend or payouts') and provides pack options. Does not explicitly name alternatives or when-not-to-use, but the context is clear enough to separate from other buy 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 must carry the transparency burden. It discloses that the tool is a legacy alias, which is useful, but gives no information about side effects, permissions, failure modes, or the exact behavior inherited from create_campaign. The alias relationship is helpful but minimal.

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, compact sentence that front-loads the key fact ('legacy alias') and adds historical context parenthetically. Every word contributes meaning, with no 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 low-complexity alias tool, this description is nearly complete: it tells the agent this is a deprecated alias and points to create_campaign as the current tool. It does not explicitly direct the agent to the canonical tool's documentation or address the schema inconsistency, so it loses one point.

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 requires placementId but provides no property definition or description. The description only hints at 'pre-ad-unit naming' and does not explain what placementId means, its format, or how it relates to create_campaign's parameters. The tool name allows inference, but the description does not compensate for the schema gap.

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 a legacy alias of create_campaign, which is a specific verb+resource referent and avoids tautology. It also explains the historical context with 'pre-ad-unit naming'. It does not explicitly say what action the tool performs, so it does not reach a 5.

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

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

'Legacy alias' signals that this is a backwards-compatibility shim and implies that create_campaign should be preferred. It names the alternative tool explicitly. It does not provide full when-to-use/when-not-to-use conditions, but the deprecation signal 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?

With no annotations, the description must fully disclose behavioral effects. It mentions the payout split (90%/10%), but omits critical details such as whether the action is irreversible, whether it requires sufficient escrow balance, failure conditions, or any side effects beyond fund distribution.

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, concise sentence that conveys the core action and business outcome. It is front-loaded and free of fluff, though it could have incorporated parameter guidance without becoming overly long.

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 financial transaction with no annotations and no output schema, the description lacks essential context about preconditions, response behavior, error cases, or whether the action can be reversed. The payout split is useful but insufficient for safe invocation.

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

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

The single parameter campaignId has 0% schema description coverage, and the tool description does not explicitly mention 'campaignId' or explain that it identifies the campaign to confirm. The description only implies the campaign context, leaving the parameter's role to inference.

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: 'Advertiser releases escrow after confirming ad delivery/attribution.' This names the verb (releases escrow) and the resource (ad delivery/attribution), and distinguishes it from siblings like deliver_ad (publisher-side) and report_conversion (attribution reporting).

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 'after confirming ad delivery/attribution' implies a precondition but provides no explicit guidance on when to use this tool compared to alternatives. There is no mention of exclusions or related tools, leaving the usage context somewhat vague.

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 transparency. It discloses the key side effect: 'Debits advertiser credits into escrow,' and explains the purpose of couponCode and postbackUrl for attribution. It does not mention reversibility or failure behavior, but covers the most critical mutation.

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

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

The description is concise at roughly three sentences and front-loads the main purpose. The '[Buy]' prefix and alias list add a bit of bulk, but overall no sentence is wasted; it packs essential guidance into a compact format.

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 16 parameters and no output schema, the description covers the core flow (booking, escrow, optional attribution, follow-up coupon) but omits many optional fields and does not indicate what the response contains. It is sufficient for basic use but leaves gaps for edge cases.

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 low at 38%, so the description must compensate. It adds meaning to adUnitType (prefer agent-directed types) and budgetCredits (escrow), and clarifies couponCode/postbackUrl roles. However, many parameters like feedType, productId, durationDays, and product snapshot fields are not explained in the description.

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

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

The description opens with 'Create an ad campaign booking on a placement,' a specific verb and resource, and distinguishes itself from create_coupon by noting it should be used after booking. It also lists aliases buy_campaign and buy_placement, clarifying sibling tool names.

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

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

Explicit guidance is given on when to use this tool: 'prefer agent-directed cpr/cpia/cppromo/cpd to reach the agent's own recommendation/decision path instead of a human click.' It also tells the agent to 'use create_coupon to attach an agent-readable promo payload for cppromo units' after booking, providing a clear alternative for a related task.

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 explains the payload structure and delivery mechanism, but lacks mention of side effects like cost, persistence, or reversibility. As a creation tool, this information would be valuable, but the description provides some useful context beyond a simple 'create' statement.

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

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

The description is two sentences, front-loading the primary action and then adding relevant contextual detail. There is no filler; every clause contributes to understanding the tool's purpose and application.

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

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

Given the tool's complexity (11 parameters, nested objects, no output schema), the description covers the main purpose and use cases but omits important contextual details such as return value format, cost implications, and required campaign ID semantics. The schema fills many gaps, but the description alone is not fully complete for a tool of this complexity.

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

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

Schema coverage is 82%, so most parameters are already well-documented. The description adds value by explaining how parameters map to the machine-readable offer payload (e.g., percent_off or amount_off, valid_until, redeemUrl) and how they are used by agent instructions. This enriches understanding without redundantly repeating schema 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 core action: 'Generate one or more coupon/promo codes attached to a campaign.' It distinguishes between cppromo agent coupons and legacy cpa/cpl/cpi offers, making it easy to differentiate from sibling tools like create_campaign or deliver_ad.

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

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

The description gives explicit context for when to use the tool: for cppromo campaigns as a machine-readable payload delivered via deliver_ad, and for end-user redemption on legacy offers. It does not explicitly state when not to use it, but the context is sufficient to infer appropriate usage.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It clarifies that the tool does not bill automatically and mentions geo_mismatch rejection. However, it does not disclose other behavioral traits like authentication requirements, rate limits, or what happens if the campaign is invalid or expired.

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 long 4-sentence paragraph. It packs important information but is not front-loaded with the most critical action. The first sentence puts the agent role in brackets and uses jargon ('cpr/cpia/cppromo/cpd units') that could be streamlined. It earns its keep but could be more 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?

Given there is no output schema, the description does not explain what the return payload looks like (e.g., fields like code, percent_off, valid_until). For a fetch tool, the response format is critical. The description mentions some payload fields in passing but does not describe the structure. The sibling tools are complex, and the description adequately distinguishes this tool from report_* tools, but completeness is limited by the missing output information.

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 67%, with two parameters (geo, country) already having descriptions. The description adds context that country is required for geo-safe serve and that server rejects on mismatch, but it does not add meaning for campaignId beyond what the schema provides. It also explains the alias relationship between geo and country.

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 that the tool fetches creative and coupon/promo payload for a campaign. It specifies 'agent-directed pull' and the context in which the data is injected (recommendation/decision context). This differentiates it from simply delivering an ad, though the specific verb 'deliver' in the name is somewhat inconsistent with the actual action ('fetch').

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

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

The description explicitly states that the tool does not bill by itself and directs the agent to use report_impression or report_conversion after acting on the payload. It also explains when to pass the country parameter for geo-safe serve and what happens on mismatch. However, it does not explicitly say when NOT to use this tool versus alternatives like request_platform_demand.

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 ~15m analytics lag, states 'credits_earned is always 0 on buy side', clarifies UTC timezone, and explains the cash peg (100 credits=$1). These are meaningful behavioral traits beyond simply describing a report retrieval.

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

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

The description is dense but front-loaded, starting with the core purpose and then enumerating key output fields. Every sentence carries information about semantics, lag, or usage. While it is long, it is well-structured and scannable enough for an agent to extract essential facts quickly.

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 there is no output schema, the description compensates by listing return fields (credits_spent, stripe amounts, cash estimates, CTR/CVR) and explaining key behaviors like credits_earned always 0 and the 15m lag. It could be more complete regarding the shape of the 'series' and error/empty cases, but it is largely sufficient.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds some context by listing period values inline ('daily|weekly|monthly|range') and noting UTC, but it doesn't add substantial meaning beyond what the schema already describes for each parameter.

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: 'See what you spent for any day, week, month, or custom range'. It identifies the resource as advertiser spend and mentions a specific alternative (get_attribution) for one-campaign postbacks. However, it does not explicitly distinguish itself from the sibling tools get_advertiser_report_by_campaign and get_advertiser_report_by_placement.

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 alternative: 'For one-campaign postbacks use get_attribution.' It also gives context about the analytics warehouse lag (~15m), implying it is not real-time. It doesn't, however, provide guidance on when to use this tool versus the by_campaign/by_placement report variants.

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 adds context about ad spend vs Stripe purchases and USD estimates at 100 credits=$1. Still, it does not disclose the return format, whether results are paginated, or what happens when campaign_id is omitted. This is acceptable for a read-focused report 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 one dense sentence that front-loads the core purpose and uses a sibling reference to avoid repeating field definitions. The '[Buy]' prefix is enigmatic but not distracting. Overall, every piece earns its place without wordiness.

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 there is no output schema, the description points to get_advertiser_report for money fields, which helps define expected return values. However, it doesn't explicitly describe how 'breakdown by campaign' appears in the response or how period modes map to date parameters. The schema covers parameters, but the description relies on sibling context for full understanding.

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 fully documents all 8 parameters. The description repeats the period enum and notes campaign_id is optional, adding no new meaning beyond what the schema already provides. It does not clarify how the date parameters (date, month, start/end, week_start) interact depending on period.

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 'Advertiser period breakdown by campaign' with 'same money fields/legend as get_advertiser_report,' specifying the exact resource (advertiser report) and scope (per-campaign). The name itself also distinguishes it from sibling tools like get_advertiser_report by_placement.

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

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

It references get_advertiser_report as the baseline for money fields/legend, implying this tool is used when a campaign-level breakdown is needed. The period enum is shown, and campaign_id is noted as optional. However, it does not explicitly state when NOT to use this tool or mention the by_placement alternative.

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 behavioral disclosure burden. It states the output matches the 'same money fields/legend as get_advertiser_report', giving useful context about return format, and notes placement_id is optional. However, it does not explicitly mention that the operation is read-only, lacks any permission or side-effect disclosure, and does not describe pagination or date handling beyond the schema.

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

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

The description is concise and front-loaded with the primary purpose. It uses three short fragments to convey the breakdown type, field reference, and key parameters, avoiding fluff. The '[Buy]' prefix is a minor structural oddity but does not significantly hinder comprehension.

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 being brief, the description covers the essential context: it identifies the report type, points to get_advertiser_report for output fields/legend, and mentions optional placement_id and period modes. With no output schema and no annotations, this compensates reasonably. However, it does not self-containly explain the exact return structure or prerequisites, but the reference to a sibling tool helps.

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

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

Schema description coverage is 100%, so the schema already documents each parameter well. The description adds minimal value by restating that placement_id is optional and enumerating period modes, which are already in the schema. It does not explain parameter dependencies or provide examples beyond what the schema offers, aligning with the baseline for high 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 provides an 'Advertiser period breakdown by placement bought' and references get_advertiser_report for field definitions, making the resource and scope explicit. It distinguishes itself from sibling report tools by specifying 'by placement'. However, the '[Buy]' prefix is ambiguous and the verb 'breakdown' is used as a noun, slightly reducing clarity.

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

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

Usage is implied: use this for a per-placement breakdown of advertiser reports, with optional placement_id filtering. It does not explicitly state when to use this instead of sibling tools like get_advertiser_report_by_campaign, nor does it exclude any scenarios. The reference to get_advertiser_report for fields is a pointer, not an alternative, so guidance is moderate but not 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 carries the full burden of behavioral disclosure. It discloses the specific types of data returned (impressions, clicks, conversions, coupon redemptions, spend, postback log), which is substantial. However, it leaves 'recent events' undefined and does not explain the '[Buy]' prefix (potential cost) or explicitly state that it is read-only.

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

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

The description is two sentences. The first sentence front-loads the tool's purpose and output, and the second provides a clear alternative. 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 description gives a strong overview of the tool's scope and output, but it omits details about the time window ('recent'), any associated costs (implied by '[Buy]'), and does not specify the return structure (no output schema). For a tool with no annotations, these gaps matter, though the listed output fields partially compensate.

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 0%, so the description must compensate but does not. It mentions 'conversions by type' which loosely aligns with the groupBy=conversionType enum, but it does not explain the 'day' or 'placement' options or provide any parameter-level context. The schema is clear on its own, but the description adds no value for parameter understanding.

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 'Single-campaign attribution deep dive (recent events)' with a specific verb and resource, and enumerates concrete output fields (impressions, clicks, conversions by type, coupon redemptions, spend, postback delivery log). It also distinguishes from sibling tools by directing to 'get_advertiser_report*' for period rollups.

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 an alternative use case: 'For period rollups across campaigns prefer get_advertiser_report*.' This clearly tells the agent when NOT to use this tool and when to use a sibling, satisfying the requirement for explicit 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 does add useful context: the scope restriction 'you are party to' (implying authorization/viewing restrictions) and the conditional 'if available' (indicating the summary may or may not be present). However, it does not explain error behavior, what happens when the campaign does not exist, or whether any side effects occur (though it appears to be a read 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 sentence, which is appropriately brief and front-loaded with the core purpose. However, the leading '[Buy]' label is unexplained and may introduce ambiguity or noise. While not disruptive, it is not fully earned, so the structure is good but not flawless.

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 single-get tool with one parameter and no output schema, the description covers the key aspects: what it retrieves (one campaign booking), the access scope (party to), and the inclusion of a delivery/attribution summary when available. It does not describe return structure in detail, but given the simplicity and the mention of the summary, it is reasonably complete 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?

The input schema has one parameter, campaignId, with no description, and the description does not explicitly explain what campaignId refers to or how it relates to the 'campaign booking'. Schema description coverage is 0%, so the description must compensate, but it only refers to the resource as 'one campaign booking' without stating that campaignId is the identifier. The agent is left to infer the connection.

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' with the resource 'one campaign booking' and adds a scope constraint ('you are party to'). This clearly distinguishes it from sibling tools like list_campaigns (plural listing) and buy_campaign/create_campaign (creation). The phrase 'including delivery/attribution summary if available' further clarifies the tool's specific output focus.

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 is provided about when to use this tool versus alternatives. There is no mention of when not to use it, nor any reference to related tools such as list_campaigns or get_attribution. Usage is only implied by the verb 'Get', which is insufficient for an agent deciding between similarly named 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?

The description discloses the return fields, the state transitions, and importantly the latency and fail-open behavior ('~1500ms fail-open'), which is critical for an agent deciding to call the tool. Since no annotations exist, this transparency is valuable.

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 dense sentence delivers all necessary information: the tool's purpose, the state machine, and the response contents. No 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?

Given no output schema, the description adequately enumerates the return fields (nextStep, suggestedTools, platform demand funding status, latency guidance) and the state model, making the tool's behavior sufficiently clear for invocation.

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

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

The tool has zero parameters, so the schema is complete. The description adds meaningful context about what the tool returns rather than parameter specifics, but with zero parameters there is nothing to explain.

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 'Diagnose' with a clear resource 'publisher activation state' and enumerates the full state progression, distinguishing it from report tools like get_publisher_report which return analytics, not activation diagnostics.

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

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

It provides context by labeling the tool '[Sell]' and explaining the state chain, implying it should be used when a publisher's activation status needs to be assessed. However, it does not explicitly state when not to use it or name alternative tools, unlike get_calls which mentions search_calls_extensive.

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 any annotations, the description fully discloses key behaviors: net calculations after a ~10% fee, gross credits, platform fee, cashout fields, USD peg, analytics warehouse lag (~15m), and publisher_id scoping. This gives the agent a strong understanding of the tool's operational traits.

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

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

The description is information-dense but well-organized into three sentences, front-loading the core purpose. It covers the main output fields and operational details without excessive verbosity, though the middle sentence is a long list that could be slightly restructured for readability.

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

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

Given no output schema, the description comprehensively outlines expected return data (itemized totals, daily series, money fields) and limitations (lag, scope), covering all period modes and cost breakdowns. This is complete enough for an agent to understand the report's content and invoke it properly.

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 descriptions already cover 100% of parameters, including formats and defaults. The description adds minimal extra parameter meaning beyond reiterating period modes and specifying UTC, which is already implied by the date formats. Thus it meets the baseline but does not significantly enhance schema 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?

Purpose is explicitly stated: 'See what you earned for any day, week, month, or custom range' with period options clearly enumerated. It distinguishes from sibling publisher reports by emphasizing general scope ('Scoped to your publisher_id') versus per-campaign/per-placement variants.

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 (publisher earnings, various time periods) but does not explicitly mention alternatives or exclusions like get_publisher_report_by_campaign or by_placement. Usage is implied rather than directly contrasted with siblings.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the report excludes advertiser PII and matches the money fields/legend of get_publisher_report, which adds valuable behavioral context. However, it does not explicitly state read-only semantics, authentication, or rate limits, but 'report' implies a safe read 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?

A single sentence that packs in the tool's purpose, scope, and relation to another tool, without fluff. The [Sell] tag provides additional context and the sentence is front-loaded with the core functionality.

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 references get_publisher_report for field details, which is helpful but requires the agent to know that tool. The schema fully documents parameters, and the description gives enough context for a report tool. However, the lack of an output schema means the agent must rely on the referenced tool for response structure.

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

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

Schema coverage is 100% for all 7 parameters, so the baseline is 3. The description adds minimal extra meaning beyond the schema, such as the optional nature of campaign_id and the period enum, which are already present. The note that campaign_id 'must be on your placements' is a minor enhancement.

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

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

The description clearly states it provides a 'Publisher period breakdown by campaign on your placements' and distinguishes itself from sibling tools like get_publisher_report_by_placement via the 'by campaign' qualifier and reference to 'same money fields/legend as get_publisher_report'.

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 campaign-level publisher reporting with an optional campaign_id filter and notes the absence of advertiser PII. It gives clear context but does not explicitly mention alternatives or when-not-to-use, though the name and reference to get_publisher_report provide a clear use case.

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 money fields (credits_earned vs gross charged, platform fee, cashout, USD estimates) and period modes, which adds useful behavioral context. However, it does not mention potential side effects (e.g., read-only nature), authentication requirements, rate limits, or error behavior, leaving some gaps for a reporting 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 appropriately sized: it front-loads the core purpose and then adds detail on money fields, placement_id, and period modes. Each sentence earns its place without excessive verbosity, making it easy to scan and 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?

Given the 7 parameters and no output schema, the description provides the core context (placement breakdown and money fields) but lacks details such as how period modes map to date parameters, expected row structure, pagination, or timezone handling. It is minimally complete for an agent to infer usage but leaves some ambiguity for full understanding.

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 provides 100% coverage of all 7 parameters with clear descriptions, so the baseline is 3. The description redundantly notes 'Optional placement_id' and the period enum values, but it does not add meaning beyond what the schema already conveys, such as parameter relationships or special formatting.

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 'Publisher period breakdown by placement', which is a specific verb (breakdown) and resource (publisher report by placement). It distinguishes itself from siblings by referencing 'same money fields/legend as get_publisher_report' and by the placement-specific scope, making it clear this is a placement-level variant.

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 context: it's for publisher reporting broken down by placement, and the reference to get_publisher_report suggests a similar field structure. However, it does not explicitly state when to use this tool against alternatives like get_publisher_report_by_campaign, nor does it provide exclusions or conditions for selection.

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 transparency burden. It discloses the scope ('TikTok US Shop') and hints at read-only behavior via 'Fetch', and lists returned fields (image.url, price.*, tracked clickUrl). However, it does not detail edge cases, auth requirements, or error behavior, which would enrich 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 concise sentences that front-load the core function. The bracket prefix and HTTP endpoint are minor additional details that do not detract from clarity or add unnecessary 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 single-parameter fetch, the description provides enough to understand the operation and gives a hint of the return shape via listed fields. However, the lack of an output schema and absence of error handling mentions leave some minor gaps, preventing a perfect 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?

Schema coverage is 100% with the description 'Product id from search_tiktok_products.' The tool description adds no extra meaning beyond the schema, 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 'Fetch' and identifies the resource as 'TikTok US Shop ProductRecord' with a unique id. It clearly distinguishes from the sibling search_tiktok_products by focusing on retrieving a single record by id, and even lists key fields returned.

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 and parameter schema together imply the tool is used after search_tiktok_products, since the id is stated to come from there. This provides clear context for when to use it, though it doesn't explicitly state exclusions or alternative scenarios.

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 behavioral disclosure burden. It does add useful context about including escrow and delivery statuses, but it doesn't disclose pagination behavior, default ordering, or whether all campaigns are returned or just active ones. For a read-only list operation, this is a moderate 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 a single, front-loaded sentence with no wasted words. The verb 'List' appears first, and the sentence concisely covers the resource and key details. The odd '[Buy]' prefix is minor noise but doesn't reduce readability.

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 list tool with optional parameters and no annotations or output schema. The description explains the basic purpose but omits important context such as response format, pagination, and defaults. Given the lack of other structured metadata, it should have revealed more about what the tool returns and how it behaves.

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 0% description coverage, so the description must compensate for both parameters. The phrase 'as advertiser and/or publisher' clarifies the role parameter, but limit is completely ignored. This partial compensation is insufficient for full clarity, so a 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 'List' with a clear resource, 'ad campaign bookings,' and further specifies the scope by role (advertiser/publisher) and included statuses (escrow + delivery). This clearly distinguishes it from sibling tools like get_campaign (singular) and create_campaign.

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 it: when you need to list campaign bookings for your roles. It explicitly mentions the role filtering capability, providing clear context. However, it doesn't mention alternatives or exclusions, such as when to use get_campaign instead, so it doesn't fully reach a 5.

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

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

With no annotations, the description carries the full burden. It discloses that the tool returns coupon codes with redemption status, implying a read-only operation. However, it omits details about pagination, default status behavior, or error handling, so it is not fully 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, concise sentence with the main action front-loaded. The leading '[Buy]' is extraneous and does not contribute meaning, which slightly reduces the score, but the rest is tight and effective.

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 list tool with no annotations or output schema, the description covers the core action and purpose, but it does not fully explain the response format, default filters, or how limit behaves. It is adequate but leaves gaps for an agent to infer.

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 description adds meaning to campaignId (target campaign) and status (redemption status), which the schema does not explain. However, the limit parameter is left undocumented beyond its schema constraints, and no other parameter details are clarified.

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 ('List'), resource ('coupon codes for a campaign'), and adds the distinguishing feature of redemption status. It also explains the purpose (attribution audits), which sets it apart from sibling tools like list_campaigns or create_coupon.

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

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

It gives clear context for when to use the tool (cpa/cpl/cpi attribution audits) but does not explicitly mention alternatives or when not to use it. This is a clear use case without exclusions, matching the '4' criterion.

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 only states that the tool lists messages, without any details on pagination, ordering, access controls, or potential side effects—all of which are unknown to the agent.

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 concise sentence that is easy to parse. However, the leading '[Buy]' prefix is unexplained and could be seen as extraneous noise, slightly reducing the overall efficiency.

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 absence of annotations and output schema, the description is too sparse for the agent to understand pagination, result format, or edge cases like empty threads. It provides minimal context beyond the fundamental action.

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 0% description coverage, and the description adds no explanation of the parameters. While 'campaignId' is semantically tied to the 'campaign booking thread', 'limit' is entirely unexplained. The description fails to compensate for the lack of parameter documentation.

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

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

The description clearly states the tool's action ('List messages') and the resource ('a campaign booking thread'), with context that it involves advertiser and publisher. This distinguishes it from sibling tools like send_message, which handles the opposite action.

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 action is unambiguous, implying use when the agent needs to retrieve messages on a thread. However, there is no explicit guidance on when to use this tool versus alternatives, no exclusions, and no mention of prerequisites or context that would help choose between this and similar list 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 transparency burden and discloses important behavioral details: the platform fee (10%), the need to call request_platform_demand after listing, and the strategic distinction between agent-directed and legacy ad units. It does not mention reversibility, required permissions, or the shape of the response, but it provides more behavioral context than a typical minimal description.

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

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

The description is front-loaded with '[Sell] Create an ad placement' and each subsequent sentence contributes useful detail (unit types, audience guidance, fee, follow-up). It is somewhat dense with parenthetical expansions, but still readable and earns its length.

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

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

The tool has 7 parameters, no annotations, and no output schema, and the description covers core aspects: purpose, required fields, fee, and next step. Gaps remain around the return value (only placementId is implied), authentication/authorization prerequisites, and how errors or duplicates are handled, so it is not fully complete.

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

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

Schema description coverage is 71%, and the description adds meaningful semantics for adUnitType by explaining that agent-directed units 'sell the agent's own context/decision path, not a human click' and that legacy units are for 'human-adjacent funnels.' It reinforces the description parameter ('Describe audience + surface') but adds nothing for the undocumented 'kind' and 'title' 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 'Create an ad placement (inventory slot)' with a specific verb and resource, and the '[Sell]' prefix clarifies that 'list' means listing for sale rather than enumerating. However, the name 'list_placement' is ambiguous next to siblings like 'search_placements' and 'list_campaigns', and the description does not explicitly differentiate it from those tools.

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

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

It gives clear in-tool guidance: 'Prefer agent-directed units' vs 'Legacy cpm/cpc/cpa/cpl/cpi remain for human-adjacent funnels,' and instructs to 'Describe audience + surface.' It also directs the follow-up action 'call request_platform_demand(placementId) to fund first fill.' However, it does not explicitly state when not to use this tool or mention alternatives like 'use search_placements to view existing placements.'

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 discloses critical behavioral traits: the API key is one-time and shown only once, meaning it cannot be retrieved later. It also implies non-repeatability via 'Call once per install.' It does not detail effects of repeated calls or side effects, but covers the most important behavior.

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 and front-loaded with 'Create a new MoltAd network identity,' immediately stating the action. Every sentence delivers value: 'Call once per install' and 'Store apiKey; shown once' are critical instructions. 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 registration tool with no output schema, the description covers the return value and key usage constraints. However, it omits edge-case behavior such as what happens if the tool is called twice, and the '[Shared]' prefix is unexplained. Despite these gaps, the tool's simplicity makes it largely 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 50%, and the description maps 'advertiser and/or publisher' to the role parameter but does not compensate for undocumented params like provider or displayName. The description adds marginal value beyond the schema's enum and parameter names.

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 creates a MoltAd network identity and returns a one-time API key, distinguishing it from sibling tools like register_postback. The verb 'create' and resource 'network identity' are specific and unambiguous.

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

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

The description provides clear usage context with 'Call once per install' and 'Store apiKey; shown once,' which is essential for correct use. However, it does not explicitly exclude alternatives or mention prerequisites such as being unregistered.

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. It discloses that the tool creates/updates a postback and that MoltAd will fire it on report_conversion with an HMAC signature. However, it does not mention whether existing postbacks are overwritten, what auth/permissions are needed, or what response to expect, leaving notable gaps for a mutation tool.

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

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

The description is two sentences, front-loaded with the action and resource, and adds a concise behavioral note about the trigger and signature. Every word earns its place with no 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?

Given the tool has 4 parameters and no output schema, the description plus schema covers the essential workflow: what to provide, what happens when the event occurs, and the signing mechanism. It lacks some detail about return values or failure modes, but the context is sufficient for correct invocation in most cases.

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 50%: events and secret have descriptions, while campaignId and postbackUrl do not. The description adds meaning by explaining the postback URL is server-to-server and that the secret is used for HMAC signing, but it does not further elaborate on campaignId or the events array beyond what the schema already provides.

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 'Register or update a server-to-server postback URL + secret for a campaign', naming the exact action, target resource, and scope. It also distinguishes this tool from siblings like report_conversion by explaining that MoltAd fires the postback on conversion events.

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 clear context for when to use the tool: to set up or modify postback notifications for a campaign. It mentions the trigger event and use case (cpa/cpl/cpi), effectively implying the appropriate scenario, though it does not explicitly name 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 full burden. It only discloses a tip about attaching context.requestId, but does not explain the side effects of filing a bug report (e.g., whether it creates a ticket, notifies support, or is reversible). This is a significant gap for a tool with no safety 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 purpose, and every word adds value. The tip about context.requestId is a succinct, actionable 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?

Given 9 parameters, no output schema, and no annotations, the description is too brief to be complete. It does not explain the purpose of most fields, the expected behavior of the tool, or the outcome. Only a single usage hint is provided.

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 0%, and the description only adds meaning to the context.requestId field. The other 8 parameters (title, description, severity, etc.) are left unexplained, so the description does little to compensate for the lack of schema 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 verb 'File' and resource 'bug report for MoltAd platform support,' which is specific. However, it does not explicitly contrast with sibling tools like ask_help, though 'bug report' implies a distinct use case.

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

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

The description provides clear context: use this when filing a bug report, and specifically attach context.requestId from failed API responses. It does not mention when not to use it or alternatives, but the scenario 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 provided, the description carries the burden. It discloses the return value (clickId) and its purpose (correlation with later conversion/postback), which is helpful. However, it does not mention side effects (e.g., billing impact, idempotency), authentication requirements, or duplicate handling, leaving gaps in behavioral understanding.

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 and followed by the return value. Every word earns its place; 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?

The tool has 4 parameters, a nested object (context), no output schema, and no annotations. The description covers the primary purpose and return value but omits essential details about parameter semantics, especially for context and occurredAt, and does not explain the structure or constraints of the request. This is insufficient for the tool's complexity.

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

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

Schema coverage is only 25% (only clickId has a description). The tool description does not compensate for the other parameters (campaignId, occurredAt, context). campaignId is implied by 'campaign booking', but occurredAt and context are completely unexplained. The description adds no meaningful semantics beyond the bare parameter names.

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 ('Report a click event') and the resource ('campaign booking'), with specificity about ad types (cpc, cpa/cpl/cpi click leg). It distinguishes itself from sibling tools like report_impression and report_conversion by focusing on click events.

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: for click events on cpc units or the click leg of cpa/cpl/cpi. It implies the tool is not for impressions or conversions, though it does not explicitly name alternatives or exclusions. This is sufficient but not exhaustive.

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

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

Since no annotations are provided, the description carries the full behavioral burden. It discloses that reporting triggers billing and the campaign's postback if registered, and it clarifies the meaning of each conversion type. However, it does not mention error handling, authentication requirements, or return values, leaving some gaps in 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 and front-loaded, delivering the core purpose in the first sentence and efficiently listing conversion types in a structured way. Every sentence earns its place, with no redundant elaboration.

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 annotations and no output schema, the description covers the main purpose, side effects, and parameter usage for critical fields. It could be more complete by mentioning response format or error conditions, but the core context is well-addressed given the tool's moderate complexity.

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

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

The description adds significant semantic meaning for conversionType by defining each enum value and links couponCode to the deliver_ad payload. With only 43% schema coverage, it compensates well for key parameters but omits context, occurredAt, and valueCredits, which are still documented in the schema.

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

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

The description clearly states what the tool does: reports an event that bills a conversion unit. It explicitly enumerates the valid conversion types (recommendation, decision, coupon_redeemed, and legacy cpa/cpl/cpi) and explains their semantics, distinguishing it from sibling tools like report_click and report_impression.

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 usage context by mapping each conversion type to its specific scenario (e.g., recommendation surfaces an offer, decision in a multi-option step) and instructs to correlate with clickId when available. It does not explicitly name alternatives to avoid, but the context strongly implies it is for conversion reporting, not click or impression 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?

With no annotations, the description must carry the full burden of behavioral disclosure, but it only restates the purpose. It does not mention whether this is a write operation, what happens to the submitted report, any permissions required, or potential side effects. For a tool with zero annotation coverage, this 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 a single, front-loaded sentence that conveys the tool's core purpose in under 20 words. 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?

Given the tool's complexity—six parameters, a nested object, no output schema, and no annotations—the one-line description is insufficient. It fails to specify the meaning of 'context', 'provider', or the distinction between success and friction inputs, leaving the agent guessing about important parts of the invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It names 'rating' and 'journeyStep' and hints at 'whatWorked'/'whatFailed' via 'success or friction', but leaves 'context', 'provider', and the exact roles of other parameters unexplained. This partial coverage is above baseline but incomplete.

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 ('report') and resource ('success or friction while using MoltAd'), and mentions the key inputs (rating + journey step). This distinguishes it from sibling tools like report_bug, report_click, and report_conversion, which target specific event types.

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 makes the context clear: use this tool to report user experience (success or friction) within MoltAd. It does not explicitly name alternatives or exclusion criteria, but the purpose is specific enough to infer when it applies, 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 burden. It adds useful behavioral context (cpm vs cpia, batchability, feeds billing), but it does not disclose details like idempotency, error handling, or side effects on billing.

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, information-dense sentence that leads with the verb and resource. Every clause adds value (cpm/cpia distinction, batchability, billing impact), 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 no output schema and no annotations, the description adequately covers purpose but lacks details on response format, context object structure, and potential side effects. It is sufficient for basic selection but not full autonomous invocation.

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

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

Schema coverage is 50% (count and occurredAt are described). The description's distinction between cpm and cpia hints at the 'context' parameter's meaning, but it does not explicitly define campaignId or context, leaving some ambiguity.

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 ('Report') and resource ('ad impression events for a campaign booking'), and clarifies the distinction between cpm and cpia, which differentiates it from sibling reporting tools like report_click and report_conversion.

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 context is clear: this tool is for ad impression events, not clicks or conversions. It also mentions 'Batchable' as a usage capability. However, it does not explicitly exclude alternatives or name when-not-to-use scenarios.

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 a key behavioral trait: credits are escrowed and the platform settles the BTC payout later, indicating a delayed process. This adds real value beyond the basic action, though it does not mention reversibility or failure conditions.

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

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

Two sentences, front-loaded with the action, no redundant words. The escrow/settlement detail earns its place by adding behavioral context. Perfectly concise.

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 financial tool with no annotations, no output schema, and 0% parameter coverage, this description is too thin. It explains the basic flow but omits critical usage details like what paymentDetails is for, why btcAddress is optional, and what the platform does after escrow. The agent would likely need external knowledge to invoke this 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 0%, and the description provides no parameter-specific information. The names creditAmount, btcAddress, and paymentDetails are self-referential, but the description does not clarify their roles or the optional nature of btcAddress. The mention of 'earned credits' only hints at creditAmount, leaving other parameters unexplained.

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 ('Request') and resource ('Bitcoin cashout of earned credits'), clearly distinguishing this from sibling tools like wallet or buy_credits. It also adds context about escrowing and settlement, making the purpose unambiguous.

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

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

The description implies use when you have earned credits and want a BTC payout. It does not explicitly name alternatives or exclusions, but the context is clear enough to infer when to use it versus other financial tools. No explicit when-not guidance is given, but the purpose is specific.

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

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

With no annotations, the description carries full burden. It discloses idempotency, prerequisites (wallet credits), and country preference behavior. However, it does not explain side effects (e.g., credit deduction, campaign creation details) or error states beyond referencing docs for empty wallet.

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 relatively concise (6 sentences) and front-loaded with the core action and category tag. Every sentence adds value, though some phrasing (e.g., 'so you can deliver_ad and earn in one sitting') could be slightly more efficient without losing meaning.

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

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

Given 5 parameters, no output schema, and no annotations, the description covers the main purpose, prerequisites, and idempotency but omits what the tool returns (e.g., campaign ID) and how it fits into the broader workflow beyond its link to deliver_ad. This leaves moderate gaps for an agent to know expected outcome.

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 baseline is 3. The description adds a usage hint for the country parameter ('prefer a brand whose targeting GEO includes the end-user country') but otherwise repeats schema content for budgetCredits and brandSlug. No significant new meaning beyond 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 verb 'Book' and the resource 'platform-funded affiliate demand onto one of your placements'. It ties directly to sibling tool 'deliver_ad', distinguishing its role as a prerequisite step. The purpose is unambiguous and specific.

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 context (before deliver_ad, requires wallet credits) but does not explicitly tell when to use this tool versus alternatives like buy_campaign or search_affiliate_offers. No exclusion criteria or comparative guidance is 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 provided, the description carries the full burden. It discloses key side effects ('returns escrowed credits, cancels/closes booking') and a temporal constraint ('before campaign completion'). However, it lacks details on reversibility, failure conditions, or what happens if the campaign is already completed, which are important for a refund 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, dense sentence that front-loads the primary action and includes the key context and side effects. No filler words; every element contributes to understanding. The unusual '[Buy]' prefix is a minor label but does not detract from conciseness.

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 annotations and output schema, the description provides a reasonable overview but is not fully complete. It covers the action, timing, and side effects, but does not explain return values, prerequisites, or edge cases (e.g., partial refunds, minimum refundable amount). For a financial operation, more context would be expected.

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 0%, so the description must compensate. It does not explicitly explain the parameters, though 'campaignId' is self-explanatory and 'reason' is generic. The description adds no detail about the expected format, the purpose of 'reason', or how the refund amount is determined, leaving the agent to infer from the schema alone.

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 ('refund') and resource ('advertiser refund of unspent budget'), and it distinguishes from siblings by specifying the timing ('before campaign completion') and the effects ('returns escrowed credits, cancels/closes booking'). This is a clear, non-tautological statement.

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

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

The description implies a usage condition ('before campaign completion') and the action (refunding unspent budget), but it does not explicitly mention when not to use this tool or offer alternatives (e.g., request_cashout). There is no direct comparison to sibling tools, although the context suggests a specific scenario.

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

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

With no annotations, the description carries the full burden and discloses key behaviors: it returns only public data, never affiliate secrets/tokens, is platform-funded (not organic), and publisher agents inject these as ads. This is highly 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 concise with about 4 sentences, front-loading the purpose. It includes necessary behavioral and usage details without unnecessary verbosity, though a slight structural improvement could be made.

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

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

Given no output schema, 5 parameters, and no annotations, the description provides adequate context: what is returned, how to filter, business context, and what is excluded. It is complete enough for an agent to use effectively.

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 80% (4 of 5 parameters have descriptions). The description adds value by explaining the strict GEO filtering behavior for the 'country' parameter and mentions aliases, going beyond the schema's basic 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 lists affiliate-backed platform demand brands with specific public fields (maxRateCredits, logo URLs, creative text, deep links). It distinguishes from sibling tools like search_placements or list_campaigns by focusing on affiliate offers, and includes filtering by country.

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 specifies when to use the tool (to list affiliate offers) and how to filter by country with strict GEO targeting. However, it does not explicitly mention when not to use it or provide alternatives, though the context is sufficient for an agent.

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 transparency burden. It only mentions that placements are 'active' and does not disclose read-only safety, authentication requirements, rate limits, or response behavior. The external API mention adds routing but not 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 main purpose ('Search active ad placements'). It is concise, with no fluff, and manages to include actionable routing in a compact 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?

There is no output schema and no annotations, yet the description does not mention return fields, pagination, or edge cases. It mentions filter by kind/adUnitType but doesn't explain how they interact, and sibling list_placement is not addressed, leaving gaps in context.

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 only 20% (only offset is described), and the description only tells to 'filter by kind/adUnitType' without explaining q or limit semantics. It does not compensate for the low schema coverage or the many enumerations in the schema.

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

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

The description uses a specific verb ('Search') and resource ('active ad placements/inventory') and clearly identifies the network. It also differentiates from sibling tools by telling when to use search_affiliate_offers for affiliate-backed demand, making the purpose distinct.

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

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

It explicitly says to filter by kind/adUnitType before create_campaign, indicating when to use this tool. It also gives an alternative ('use search_affiliate_offers or GET /api/public/brands') for affiliate-backed creatives, which is strong when-not guidance.

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

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

No annotations are provided, so the description carries full transparency burden. It thoroughly discloses: geographic restriction (US-only), empty returns for non-US countries, the return structure (ProductRecord[] with specific fields), chat client limits, no-fill edge case, and a warning not to invent SKUs or deep links. This covers all key behavioral traits.

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

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

The description is six sentences, each earning its place. It front-loads purpose and geographic constraint, then return structure, limits, edge cases, REST reference, and a warning. No redundancy or fluff. Excellent structure for quick agent parsing.

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 8 optional parameters and no output schema, the description covers purpose, return fields, constraints, limits, and edge cases. It lacks pagination/sorting details and error handling, but given sibling complexity and schema richness, it is largely complete. Good, not perfect.

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 operational context (aliases, chat client limits, REST endpoint example) but does not elaborate on parameter formats or semantics beyond what the schema already provides. The added value is moderate, thus a 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 searches 'TikTok US Shop product ad units', specifies the feed type ('feedType tiktok_us_shop'), and distinguishes it from siblings like 'search_affiliate_offers' (affiliate offers) and 'get_tiktok_product' (single product retrieval). The verb 'search' combined with the specific resource makes the purpose unambiguous.

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

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

The description gives explicit context: US-only inventory, non-US returns empty, chat client limit ≤20 (default 6), and empty/feed_pending yields no-fill. However, it does not explicitly state when to use this tool over siblings (e.g., 'search_affiliate_offers' vs. 'search_tiktok_products'), so it loses a point for excluding 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?

Annotations are absent, so the description must disclose behavioral traits. It only states the action without mentioning side effects, delivery guarantees, rate limits, or authentication requirements. The '[Buy]' prefix hints at a commercial aspect but is unexplained.

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 and is efficient in length. However, the '[Buy]' prefix is cryptic and adds confusion without earning 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?

Given no annotations and no output schema, the description leaves out return behavior and side effects. For a mutation tool, it should at least note whether the send is synchronous, what happens on failure, or if there are costs. It is minimally 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?

With 0% schema description coverage, the description must explain the parameters. It does not explicitly describe 'body' or 'campaignId'; it only implies that a message is sent on a thread. The parameter names are self-explanatory, but the description adds no additional 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 uses the specific verb 'Send' and identifies the resource as 'a message on a campaign booking thread', which clearly distinguishes it from sibling tools like list_messages. It conveys the core action without ambiguity.

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

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

The description implies the tool is for messaging within a campaign booking thread, but it does not specify when to use it over alternatives, such as list_messages for reading. No exclusions or conditions 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?

No annotations are present, so the description must convey behavioral traits. It only states the action without disclosing whether deactivation is reversible, how updates are applied (partial vs. full), permissions needed, or side effects on related campaigns. The lack of detail leaves the agent unaware of potential consequences.

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 short sentence, highly concise and front-loaded with the essential action. However, given the tool's 8 parameters and lack of annotations, the description may be too sparse to be fully helpful. It earns its place but could be more 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?

The tool has a complex schema (8 params), no annotations, and no output schema, yet the description provides minimal context. It does not explain return values, the meaning or impact of updates, or the distinction between updating and deactivating. This leaves significant gaps for an agent to 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?

With only 13% schema description coverage, the description should compensate by explaining key parameters, but it mentions none. The schema lists parameters like roasRating and rateCredits without meaning, and the description adds no clarification. The only parameter described in the schema is feedType, which the description ignores.

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: 'Update or deactivate one of your ad placements.' It specifies a concrete verb (update/deactivate) on a specific resource (ad placements), and the '[Sell]' prefix indicates the domain context. This distinguishes it from siblings like buy_placement and list_placement.

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 its usage context—modifying an existing placement—but does not explicitly state when to choose this tool over alternatives like buy_placement or search_placements. It lacks guidance on prerequisites or when to use a different tool, offering only a hint from the '[Sell]' prefix.

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?

The verb 'Get' implies a non-mutating read operation, but there are no annotations to confirm read-only behavior. It provides some value by listing what is returned (ad earnings, fees, cashouts), but does not disclose other behavioral traits such as authentication requirements or any 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 a single, concise sentence that conveys the core functionality without fluff. The '[Sell]' prefix is slightly ambiguous and may add unnecessary noise, preventing a perfect score.

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

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

The tool is simple and has no output schema, so the description must fill in return expectations. It tells the agent what to expect (balance and ledger entries) but lacks specifics like the number of entries, formatting, or any limitations. This is sufficient for basic use but leaves 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?

With zero parameters, the description does not need to explain parameter semantics. The baseline is 4, and the description adds clarity about the tool's purpose without needing to cover parameter 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 'Gets' the credit balance and recent ledger entries, which is a specific verb and resource. It distinguishes this from sibling tools like buy_credits or request_cashout by focusing on reading financial data.

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 usage context is implied: use this tool to check balance or ledger entries. However, there is no explicit mention of when not to use it or alternatives, such as buy_credits to add funds or request_cashout to withdraw. The guidance is not absent but relies on 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?

With no annotations, the description carries the full burden. It discloses that the tool requires an 'authenticated' agent, which is a key behavioral trait. However, it does not mention error conditions, side effects, or whether it is read-only (though 'return' implies so). It lacks details beyond the basic return value.

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 with no unnecessary words. The '[Sell]' prefix is cryptic and unexplained, slightly detracting from clarity, but the core description is concise and to the point.

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

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

For a simple tool with no parameters, no output schema, and no annotations, the description gives a high-level overview of the return value ('identity and wallet balance'). However, it does not specify the response format or structure, nor does it describe behavior under error conditions (e.g., unauthenticated requests). This is a minor gap for such a simple 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 tool has 0 parameters, so the schema is vacuous. According to the rubric, a baseline of 4 is appropriate because there are no parameters to document. The description does not need to add parameter 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 states the verb ('Return') and the resource ('authenticated agent identity and wallet balance'), making the tool's function unambiguous. It also distinguishes itself from the sibling 'wallet' tool by combining identity with balance, and the parenthetical '(publisher identity check)' adds context.

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 via the phrase 'publisher identity check,' suggesting when it might be needed. However, it does not explicitly mention when to use this tool over alternatives (e.g., 'wallet' for balance only), nor does it state any exclusions or prerequisites beyond being authenticated.

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