CreativeScope — Mobile Game Ad Creative Intelligence

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

With no annotations provided, the description carries the behavioral disclosure burden and largely satisfies it: states returned counts and global exposure, explicitly says no standalone creative/ad IDs are returned, caps the date range at 180 days, and clarifies non-obvious country-filter semantics. It omits pagination/rate-limit details, but nothing here suggests mutating 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 four short, purposeful sentences with no fluff: purpose and scope, returned metrics, country-selection caveat, and constraint warning. Each sentence earns its place and the most defining information is front-loaded.

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

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

Since there is no output schema, the description compensates by naming the returned metrics and clearly stating the no-ID caveat. Parameter schemas already cover required fields and formats, and the description adds the non-obvious behavioral constraints that are needed to invoke this tool correctly. The picture is complete for an agent.

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

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

Schema description coverage is 100%, so the baseline is already solid. The description adds value beyond the schema by clarifying that game_ids must supply 2-5 tokens, the games share the same date range, and country_code alters the target list rather than representing geographic exposure or preference. It could more explicitly map rank_by values to the named metrics, but it substantially supplements 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 identifies a specific action and resource: compare 2-5 games under shared date-range, deduplication, and metric definitions, and it lists exact returned metrics. The cardinality '2-5' plus the cross-game comparison framing clearly distinguishes it from the many single-tool get_* siblings in the list.

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 scopes the tool to multi-game comparison with identical date range/dedup/metrics and warns that country filtering means target-list inclusion, not geographic exposure or preference. It does not explicitly name alternative tools for cases such as needing standalone creative IDs or geographic exposure, but the intended use context is clearly implied.

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 what the tool returns (business context, date, platforms, tool catalog, limits, freshness, capabilities) and mentions 'capability boundaries,' which is useful. It does not explicitly state it is read-only, but for a get-context tool this is a minor omission.

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

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

Two sentences: the first densely lists the returned context items, the second gives actionable usage guidance. No filler or redundancy; front-loaded with the tool's purpose.

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

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

For a zero-parameter tool with no output schema or annotations, the description is remarkably complete. It enumerates the full set of context elements and explains how to use the catalog to route to other tools, leaving nothing essential missing.

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 already fully covers them (vacuous coverage). The description correctly adds no parameter details, matching the baseline for parameterless tools.

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

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

The description states a specific verb ('Get') and a precise resource ('CreativeScope business context') further enumerated as current date, platforms, tool catalog, date limits, freshness, and capability boundaries. It clearly distinguishes this tool as the context provider among the many data-query siblings.

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

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

It explicitly instructs the agent to 'Use the tool catalog to select the appropriate discovery, aggregate or ranking contract,' indicating this tool should be consulted before choosing other tools. While it doesn't name alternatives or state when not to use it, its uniqueness as a context tool makes the usage context 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?

There are no annotations, so the description carries the burden. It usefully discloses that values are canonical and intended for exact filtering, but it does not explicitly address read-only behavior, auth expectations, response shape, or failure behavior. The 'Get' verb implies non-mutation, but the description itself does not confirm it.

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?

Four short sentences with no filler or repetition. The main purpose is front-loaded, and each sentence contributes either output scope, usage guidance, or parameter semantics.

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

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

For a simple, zero-required-parameter filter-options tool, the description is largely complete: it names the resource categories, the use context, and the canonical-value rule. Without an output schema, a little more return-structure detail would be helpful, but the tool's simplicity makes this a minor gap.

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

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

With 100% schema description coverage, the schema already documents the `types` parameter. The description adds value by explaining how the returned values should be used as filter parameters and by emphasizing the distinction between canonical values and user-supplied conditions.

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?

Description starts with a specific verb+resource: 'Get valid game categories, countries and 14 delivery-platform aliases.' This clearly defines the tool's purpose and separates it from the many sibling data-retrieval tools because it returns canonical filter options, not game metrics or screenshots.

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 application guidance: 'Map user conditions to the returned standard values before exact filtering' and 'Keep canonical filter values unchanged when using them as parameters.' It does not name excluded sibling tools, but the intended usage context is clear enough without requiring 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 disclosure burden and meets it: cross-month snapshot deduplication, one-result-per-plan representation, response-local plan_sequence without standalone IDs, has_more pagination rather than exact totals, and contains/exclusive semantics are all stated explicitly. This goes well beyond the structured 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?

Three dense, front-loaded sentences cover purpose, data model, matcher semantics, pagination, and the key alternative. Every sentence contributes information, and there is no filler or repetition of schema content.

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

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

For a filtered read tool with no output schema and no annotations, it covers result identity, matcher behavior, pagination, and the totals alternative. It does not fully describe the response envelope or date/range constraints, but the schema handles most parameter mechanics and the tool remains safely invocable.

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

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

Schema description coverage is 100%, so the baseline applies. The description mostly re-expresses country_match semantics that the schema already documents, and adds general plan-identity context rather than per-parameter details. It neither compensates for missing schema info nor introduces 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 opens with a specific verb-resource pair ('Discover a game's ad plans') and names the filter dimensions: countries, platforms, format, dates. It also distinguishes itself from material/ad tools by noting results have no standalone ad/creative IDs, and from get_game_platform_stats by directing totals there.

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 an explicit routing hint: 'Use get_game_platform_stats for totals.' It also clarifies contains vs exclusive country matching, which tells the agent how to choose match behavior. It does not enumerate all non-use cases, but the data-model caveats give sufficient selection context.

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

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

No annotations are present, and the description adds a meaningful behavioral caveat: country coverage can overlap and does not represent country-specific exposure or audience preference. That is genuine context beyond the schema. It still does not disclose the return shape or whether the output is per-date or aggregated.

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 focused sentences: the first states what the tool returns, the second clarifies an important interpretation trap. No filler or repetition.

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

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

For a read-only reporting tool with no output schema, the description does enough to set expectations but leaves the output shape ambiguous. The caveat about overlap is useful, but an agent still won't know whether the result is per-country, per-game, per-date, or a single aggregated object.

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

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

All four parameters are documented in the input schema with descriptions and defaults, so the schema carries the parameter burden. The description adds no new semantics about the parameters, such as how platform or game_id affect the result.

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?

Description states a specific verb and resource: 'Get game delivery-country coverage for a date range.' It also disambiguates the metric from exposure or audience preference, and the conversational definition clearly separates it from sibling tools like get_game_platform_stats or get_game_delivery_summary.

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 describes the high-level use case (date-scoped country coverage) and adds interpretative context about overlapping coverage. However, it does not explicitly tell an agent when to use this tool versus a sibling, nor when not to use it or what alternatives exist.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the semantics of each output metric, states the default (90 days) and maximum (365 days) range, and instructs to 'Label exposure as estimated.' It also hints at timezone sensitivity by referencing Asia/Shanghai. This goes beyond a simple action statement and gives useful behavioral context.

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

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

The description is moderately sized but well organized: it opens with the core purpose, defines the three metrics, then provides usage notes. There is no fluff or repetition; every sentence adds value. It is not overly wordy for the information it conveys.

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

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

For a tool with only three parameters and no output schema, the description covers the essential decision points: metric definitions, how to request historical vs period data, and range constraints. It lacks explicit details about response structure, but since there is no output schema, that may be acceptable. The description is sufficiently complete for an agent to call the tool correctly.

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

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

The input schema already covers all three parameters with descriptions (100% coverage), so the baseline is 3. The description adds practical guidance on how to choose date_from/date_to for different use cases (e.g., historical snapshot vs period total) and clarifies the default and maximum date range, which helps an agent select correct parameter values beyond the schema's basic format.

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

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

The description states a specific verb and resource: 'Get daily and cumulative estimated exposure across all Android/iOS packages associated with a game.' It explicitly defines three distinct metrics (daily_impressions, snapshot_impressions, daily_impressions_total) and scopes the operation to all packages, making it clearly distinguishable from sibling tools that cover other game metrics like delivery or trend.

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 scenario-based usage guidance for metrics: 'For historical total exposure with no date, query yesterday in Asia/Shanghai and use its snapshot_impressions' and 'For the past N days, use daily_impressions_total.' However, it does not explicitly compare this tool against alternative tools or state when to prefer this over a sibling, leaving tool-selection guidance implicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly warns that exposure is lifetime estimated exposure, not 30-day incremental, and that download_count is cumulative, not incremental. These clarifications prevent misinterpretation of numeric fields. It does not mention auth or rate limits, but for a get-style tool, safety is implied. Overall, it provides valuable semantic transparency beyond the basic purpose.

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 well-structured: one sentence stating the returned data, followed by two specific metric clarifications. It avoids fluff and front-loads the main purpose. Each sentence earns its place, and the clarifications are essential for correct interpretation. It is not overly verbose.

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

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

No output schema exists, so the description must convey what to expect. It lists the data categories but does not specify the structure or key names. It also does not mention error handling or edge cases. However, for a single-resource detail endpoint, the description covers the core information sufficiently. Given the tool's moderate complexity and that the clarifications address likely misinterpretations, this is adequate but with gaps.

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

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

Schema description coverage is 100%, so the only parameter game_id is fully documented in the schema, including instructions to pass the token unchanged. The description does not add additional parameter context beyond what the schema says. Baseline of 3 is appropriate since the schema handles the heavy lifting and no further clarification is needed.

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

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

The description clearly states the tool returns specific data: game identity, delivery platforms, countries, active ad/creative counts, and download snapshots. It also clarifies metric semantics, distinguishing it from other get_game_* tools that may return different aggregates or trends. The resource and scope are 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 does not provide explicit guidance on when to use this tool versus the many sibling tools like get_game_summary, get_game_delivery_summary, or get_game_overview. It describes what data is returned but does not state conditions or alternatives. Users must infer from the data listed, which is inadequate given the large sibling set.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that the tool returns both increments and cumulative snapshots and warns against summing cumulative snapshots, which is a useful behavioral rule. It also mentions 'requested and actual coverage dates,' implying the tool may adjust or report date coverage. However, it does not disclose potential limitations, error cases, or whether the operation is read-only (though likely, no annotation confirms). The description provides some insight but is not exhaustive.

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 efficient: two sentences that state the purpose, the return fields, and a critical data-handling instruction. It is front-loaded with the core purpose. It avoids unnecessary verbosity and every sentence earns its place. A brief mention of usage context would improve it, but for its length, it is well-structured.

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

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

The description mentions the key return fields (coverage dates, download_increment_total, latest_download_snapshot), which is important because there is no output schema. It also gives a usage tip about summing. However, it lacks context on when to use this tool versus siblings, and does not explain what 'coverage dates' mean in practice or how the tool handles missing data. For a read-only data retrieval tool, it is reasonably complete, but given its complexity and the absence of annotations or output schema, more context would be beneficial.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description does not add meaningful new semantics for game_id, date_from, or date_to; it only references 'requested and actual coverage dates,' which loosely ties to the date parameters but adds no detail. The warning about summing is a result-handling note, not a parameter explanation. Since the schema already covers the parameters, a baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: retrieving daily Google Play net download increments and cumulative snapshots for a game. It specifies the resource (game) and the data type (downloads), making it distinct from sibling tools focused on impressions, rankings, or delivery summaries. However, it does not explicitly name any sibling tools to differentiate, so it falls short of a top score.

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

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

No guidance is provided on when to use this tool versus alternatives like get_game_trend, get_game_daily_impressions, or get_game_delivery_summary. The description only offers a data-aggregation tip ('Sum increments only; never sum cumulative snapshots'), which is about how to handle results, not tool selection. There is no mention of use cases, prerequisites, 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?

With no annotations, the description must carry the behavioral burden. It does add one key clarification: 'Exposure is a lifetime reference for newly launched creatives, not a daily increment,' which prevents misinterpretation. However, it does not disclose other behavioral aspects such as read-only nature, latency, or any side effects. It is adequate but not comprehensive.

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

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

The description is two sentences with no fluff. It front-loads the main purpose, then adds a critical nuance about exposure and the default/max range. Every sentence earns its place. It is concise and well-structured.

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

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

For a read-style tool with no output schema, the description provides the core information: what it returns, the exposure semantics, and date constraints. However, it does not specify the return structure or how metrics ('materials', 'ads', 'all') map to the output. Given the moderate complexity and no output schema, it is sufficient but could be more explicit about the resulting data shape.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by stating 'Default 90 days; maximum 180 days,' which supplements the schema's date_from constraint, and clarifies exposure semantics. It does not add much beyond that, but it does compensate slightly for the schema's plain 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 states a clear verb and resource: 'Get daily newly launched creatives, reused creatives, ad plans and exposure references' and ties it to a purpose ('analyze delivery growth and creative refresh cadence'). It is specific enough to distinguish from broad siblings like get_game_trend, though it does not explicitly name a differentiator from similar trend 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 description gives default and maximum date-range constraints but provides no guidance on when to use this tool versus alternatives. It does not mention any conditions that would select this tool over others (e.g., get_game_delivery_summary or get_game_trend), nor any exclusions. The purpose is implied but not contrasted with sibling 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 behavioral burden. It discloses that no standalone material tokens are returned, each material_reference belongs to the same result item, and no exact total is present – all non-obvious traits that prevent misuse. It is clearly a read operation and does not contradict anything. It could mention pagination limits or response structure, but the key behavioral warnings are present.

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

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

The description is relatively long but every sentence serves a purpose – the main purpose, then three clarifying notes and a pointer to an alternative. It is front-loaded with the core definition, and the notes are terse. It is not bloated, but a more compact phrasing might be possible 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 complete schema coverage and no output schema, the description is nearly sufficient. It covers the purpose, fields returned, and critical usage constraints. The only omission is a description of the overall response structure (e.g., whether it is a flat list or nested), which might affect parsing, but it is not essential for calling the tool.

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

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

Schema coverage is 100%, so the schema already explains each parameter. The description adds practical meaning by linking the pagination parameters to the note about not counting by paging, and the 'by delivery performance' phrase enriches the sort_by semantics. This is a small but real increment over the schema, so above the baseline 3.

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

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

States a specific verb and resource: 'List a game advertiser's creatives by delivery performance', and enumerates the fields returned (material_reference, delivery dates, heat, reuse status, media). It explicitly differentiates from the sibling tool get_game_platform_stats by naming it for platform totals, so an agent can distinguish this from related list tools without opening schemas.

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

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

Provides explicit when-not-to-use guidance: 'No exact match total is returned' and 'never count by repeatedly paging', and names the alternative for totals (get_game_platform_stats). This is concrete and actionable, leaving no ambiguity about when to use this tool versus a sibling.

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 transparently clarifies output semantics: 'Exposure is global creative lifetime estimated exposure, not period increments or country exposure,' 'Country shares are overlapping ad-plan target coverage,' and 'No standalone creative/ad IDs are returned.' This gives useful caveats, though it does not address failure modes or empty results.

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 compact and high-signal, using five short sentences to cover purpose, input requirements, output semantics, and caveats. No redundant phrasing or filler is present.

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 moderate complexity, the description is largely complete: it lists the returned dimensions, clarifies date and range constraints, and documents important caveats like overlapping country shares and absence of standalone IDs. It could be slightly stronger by describing the high-level response shape, but the provided context is sufficient for an agent to decide whether to invoke it.

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

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

The schema already covers 100% of parameters, and the description adds meaningful guidance: game_id should be 'passed unchanged,' date values must follow 'required-date and range constraints,' and sections may be omitted for all. The descriptions clarify that date ranges must not exceed 180 days and that dates are explicit requirements.

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 'Get a game's identity, deduplicated creatives/ad plans, market and platform coverage, and delivery-cadence summary in one call,' which is a specific, actionable purpose. It also distinguishes itself from single-purpose sibling tools by emphasizing the consolidated nature of the output.

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 important usage constraints such as 'Require explicit dates, maximum 180 days' and explains optional sections with 'Omit for all.' It does not explicitly contrast with sibling tools like get_game_daily_impressions or get_game_delivery_summary, but the 'in one call' phrasing and the exclusion of standalone IDs imply when this aggregated tool is 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 behavioral disclosure burden. It clearly explains deduplication vs. first-discovered semantics, that creative counts use lifetime overlap, and that no paging is needed. It does not mention response format, rate limits, or authorization requirements, but for a counting tool the disclosed behaviors are the meaningful ones.

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 front-loaded sentences with no fluff. The first sentence states the result sorts and scope; the second clarifies the metric semantics; the third gives usage guidance. Every sentence earns its place.

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

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

For a four-required-parameter tool with no output schema and no annotations, the description covers the core behaviors: metric definitions, date-range semantics, no paging, and when to use it. It does not describe the response envelope or edge cases (e.g., empty results), but the absent output schema makes that a minor gap rather than a serious omission.

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%, giving a baseline of 3. The description adds real value by defining how date_from/date_to relate to counts: 'Creative count uses lifetime overlap; first-discovered count uses first appearance within the range.' It also reiterates the 180-day max range, reinforcing implicit schema constraints.

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

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

The description names the exact resources and metrics ('deduplicated creative count, first-discovered creative count and ad-plan count') and scopes the operation to 'one game, platform and explicit date range'. It also differentiates itself from siblings by instructing agents to 'Always use this tool for platform totals rather than counting pages from discovery 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?

Explicit guidance is given: 'Always use this tool for platform totals rather than counting pages from discovery tools' tells agents when to use it instead of alternatives. 'No paging is needed' proactively prevents unnecessary pagination calls. The explanation of dedup semantics and the 180-day cap further clarifes when the tool is 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?

The description adds a key behavioral nuance: platform coverage can overlap and shares are not exclusive audience or exposure shares. This goes beyond the raw schema and helps counter a likely misinterpretation. However, with no annotations provided and no mention of output, pagination, or other behavioral traits, the disclosure is only partial.

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

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

Two sentences, no wasted words: the first states the core function, and the second front-loads an essential data-interpretation caveat. The description is both concise and structured in the most useful order.

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 covers the essential purpose and a core caveat, but with no annotations and no output schema, it leaves the agent inferring return format and how this tool differs from closely related siblings. Adequate, but not complete enough to guide fully.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description mentions date range generally but adds no extra meaning for game_id or country_code that the schema does not already provide.

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 returning a game delivery-platform distribution for a date range—a specific verb and resource. It does not explicitly distinguish it from sibling tools such as get_game_platform_stats or get_game_publisher_platform_trend, but the purpose itself is unambiguous.

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

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

The description provides no guidance on when to use this tool versus the many sibling game-analysis tools. There is no mention of preferred conditions, prerequisites, or alternatives, leaving the agent to infer when this tool is 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?

No annotations are provided, so the description must carry the behavioral disclosure burden. It does not communicate whether the operation is read-only, what the output/trend shape is, how dates are interpreted beyond what the schema already says, or what limits apply; only the generic consistency hint is given.

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

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

Two short sentences make up the whole description and each adds something: one states the operation and the other adds a practical consistency warning. There is no filler or repetition.

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

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

The schema covers the parameters well, but there is no output schema and no annotation coverage, so the description should say something about what the returned trend looks like. It gives a usage hint but does not describe the actual returned metric/date structure, which remains an assumption for the agent.

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

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

The input schema already has 100% description coverage for all parameters, including defaults and range guidance, so the baseline is 3. The description adds no parameter-specific clarification beyond framing it as a 'date range' and 'delivery-platform' tool.

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

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

The description clearly states a specific action ('Get a game delivery-platform trend') and a scope ('for a date range'), so an agent can see what resource is involved. It does not explicitly distinguish itself from sibling tools such as get_game_publisher_platform_ratio or get_game_daily_impressions, so it misses the full sibling-differentiation bar.

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 only guidance is 'use the returned metric and dates consistently when comparing platforms,' which is a result-handling caveat rather than when-to-use guidance. It does not mention alternatives or exclusion conditions, so an agent gets little help deciding between this and related trend/ratio/delivery tools.

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

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

With no annotations provided, the description carries the full burden. It discloses scope (Google Play and iPhone App Store only), return metrics (best rank, latest rank, ranked-day count), and date range constraints. However, it does not mention authentication, rate limits, or error behavior, which are gaps for a tool with zero annotation coverage.

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

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

Two sentences with no filler. The core action is front-loaded, followed by concise details on return values, ranking types, exclusions, and date constraints. It's efficient and well-structured.

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

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

Covers the key aspects: what it returns, limitations (iPad excluded), defaults, and max range. It describes per-dimension metrics despite lacking an output schema. Pagination is implicitly covered via the limit parameter in the schema. Given the tool's complexity, it's reasonably complete, though it could mention explicit pagination behavior.

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

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

Schema description coverage is 100%, so each parameter is already documented in the schema. The description adds slight context (e.g., 'top-grossing' vs 'grossing') and clarifies default date range, but it doesn't add meaningful semantics beyond what the schema provides. Baseline 3 is appropriate per the high 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 verb (List) and specific resource (game rank markets) with detail on what dimensions are returned. It doesn't explicitly contrast with sibling tools like get_store_game_rank or get_store_game_rank_trend, but the specificity of countries, categories, stores, and ranking types distinguishes it enough for an agent to recognize its unique output.

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

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

Provides useful context about default date range and exclusions (iPad), but does not explicitly say when to use this tool versus alternatives. The guidance is implicit through the distinct return type, but there's no direct routing like 'use this instead of get_store_game_rank for aggregated dimensions.'

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

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

With no annotations, the description carries the full behavioral disclosure burden, and it does so meaningfully. It clarifies that download_increment sums daily increments over actual coverage rather than cumulative downloads or public store ranges, and it discloses the inclusion of a legacy nested summary. That goes well beyond a surface-level description, though it does not mention auth, rate limits, or error 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?

The description is two tight sentences that front-load the primary purpose, add one essential definition, and then disclose the legacy summary inclusion. Every clause carries information, and there is no padding or repetition of schema content.

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

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

Given that there is no output schema and no annotations, the description does a good job of explaining what the summary covers and one important measurement nuance. It also flags the legacy nested summary structure. It doesn't dwell on return format details, but the field-level descriptions are enough for a simple summarizing tool.

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

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

The input schema already fully documents game_id, date_from, and date_to (100% coverage), including defaults and range limits. The description reinforces the 'within a date range' context but does not add new parameter-level meaning beyond the schema. The download_increment nuance is about output fields rather than parameters, so a baseline 3 is appropriate.

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

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

The description states a specific verb ('Summarize') and a clear resource ('creatives, ad plans, lifetime exposure references and Google Play net download increments') framed by a date range. It is clearly distinct as a summary endpoint, but it does not explicitly name or contrast with sibling tools like get_game_overview, so it earns 4 rather than 5.

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

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

The description implies when to use the tool – when you need a summary of these specific fields within a date range – but it never explicitly states exclusions or compares with alternatives. There is no explicit when-not-to-use guidance, so it sits at the 'implied usage' level.

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

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

With no annotations, the description takes on revealing the key non-obvious blind spot: creative and ad counts refer to delivery activity while exposure is a lifetime reference rather than daily incremental. This is a valuable behavioral clue that prevents misassignment of metrics. It does not go further (e.g., data availability or pagination), but the essentials are conveyed.

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 that are direct and well-ordered: first the core action, then the clarifying semantic caveat. Every word earns its place, no filler.

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

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

The description covers the tool’s purpose, the most important output interpretation (exposure lifetime vs daily activity), and the parameters are fully documented in the schema. Missing an explicit output structure (since no output is present) is a minor gap; describing the outputs beyond the caveat would add robustness.

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 description does not need to repeat parameter behavior. It adds marginally by placing the date range in the context of 'daily trends', but it does not go beyond the schema's own date_to/date_from/game_id explanations. Baseline 3 is suitable.

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 retrieves delivery trends for a date range, with a specific discrepancy by distinguishing between creative/ad counts and exposure. This aligns with the pattern of sibling tools (e.g., get_game_daily_impressions, get_game_rank_trend) while making the tool's focus immediate 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 its use case (daily delivery trends) but does not explicitly differentiate from adjacent tools like get_game_delivery_summary or get_game_install_trend. No when-not-to or alternative routing is given, so the agent has to infer when to choose this over the many get_game_* 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 transparency burden. It discloses the returned information (summary, media, owning game, platform, date, and URLs) and that media_url is useful for viewing images/playables. However, it does not explicitly state whether the operation is read-only, what happens when the reference is invalid, 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 short and front-loaded with the core purpose, followed by output details and practical usage guidance. It contains a little redundancy with the phrase 'returned by this service' twice, but overall each sentence contributes useful information.

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

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

For a read-style tool with two well-described parameters and no output schema, the description conveys the important output concepts: summary, media, owning-game data, and URL usage. It is clear enough for an agent to call it and interpret the result, though it could have disclosed invalid-input behavior.

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

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

The input schema already covers 100% of parameter meaning, so the baseline is 3. The description adds some contextual value by tying material_reference to follow-up calls and media_url usage, but it does not significantly deepen the schema's parameter definitions.

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 fetches creative summary, media, and owning-game information for a material reference. It is distinct from sibling tools like search_materials_v2 or get_game_materials by emphasizing the complete material_reference returned by the service, but it does not explicitly name alternatives.

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: use this tool as a follow-up with a complete material_reference returned by this service. It does not explicitly state when not to use it or name sibling alternatives, but the legacy detail_url and follow-up framing provide enough usage guidance.

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

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

With no annotations provided, the description carries the full disclosure burden. It adds several non-obvious behaviors: that no standalone material identifiers are returned, that the material_reference from the same item must be used when citing, and that platform/country filtering is unsupported. These are meaningful beyond the schema. It does not mention read-only status or error semantics, but as a 'get' tool the non-mutating nature is reasonably implied. The description goes beyond the bare minimum.

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 five sentences, each earning its place: the first states purpose, the second lists return fields, the third gives a citation rule, and the last two state constraints. The most important information (what the tool does) is front-loaded. It is slightly longer than minimal but not verbose, and the structure is logical. A very slight redundancy exists between 'No standalone material identifiers are returned' and the citation rule, but they convey distinct aspects.

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 7 parameters with 100% schema coverage and no output schema, the description provides a good picture: it lists all return fields, states key limitations, and includes a critical usage rule (citing material_reference). It does not explain edge cases (e.g., empty results, conflicting parameters) or pagination behavior, but those are partly covered by the limit/offset schema descriptions. For a ranking tool, this is adequate and leaves few obvious gaps.

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

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

Schema description coverage is 100%, so every parameter (date, limit, offset, period, tag_name, rank_type, class_name) already has a clear description. The tool description adds little to parameter meaning—it restates that categories are optional ('optional primary/secondary category') and mentions the rising/evergreen split, but these are already in the schema for rank_type. It does not explain parameter interactions (e.g., how period and date combine) beyond what the schema states. Baseline 3 is appropriate.

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

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

The description opens with a specific verb ('Get'), a precise resource ('rising or evergreen creative rankings'), and the key dimensions (period, optional categories). It then enumerates the exact fields returned, making the tool's function unambiguous. This clearly distinguishes it from sibling tools that handle game-level or store-level rankings, and from material search/detail 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 description states its scope ('by period and optional primary/secondary category') and discloses a hard limitation ('Platform/country filtering is not supported'), which implies when not to use it. However, it never names an alternative tool or explicitly says 'use this for X, use Y for Z'. The reader must infer that get_material_detail_v2 or search_materials_v2 would be used for different needs. This is functional but lacks explicit routing.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses that results are 'directly recorded', 'bidirectional', grouped by game, and distinct from similarity or ownership evidence. This meaningfully characterizes the tool's behavior beyond the schema. It omits potential edge-case behaviors like failure modes or rate limits, but for a read-only fetch this is reasonably transparent.

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

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

Three tightly written sentences, each earning its place: what the tool finds, what it returns, and how it differs from other tools. The key differentiating caveat is placed at the end without bloating the description.

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

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

For a tool with no output schema and no annotations, the description covers the return structure well: related games, developers, appearance information, representative references, and grouping by game. Combined with the fully documented input schema, an agent has enough to invoke it correctly. Slightly more detail on interpreting 'relative appearance days' or 'representative material references' would improve completeness.

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

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

Schema description coverage is 100%, so the schema already documents both parameters effectively. The description does not add additional parameter-level meaning beyond the schema; it only reinforces that the input is a 'creative material_reference'. Baseline 3 is appropriate here.

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

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

The description states a specific verb ('Find'), a specific resource ('directly recorded reuse relationships for a creative material_reference'), and lists exact returned fields. It also distinguishes itself from similarity-based tools by explicitly saying it is 'not vector similarity or proof of ownership', which differentiates it from siblings like get_similar_materials_v2.

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 this tool is appropriate: when direct, bidirectional reuse relationships are needed. The negative clause 'not vector similarity or proof of ownership' provides a useful exclusion. However, it does not explicitly name alternative tools or state exact conditions for when to choose them, so it stops short of full routing 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 provided, so the description carries the burden. It adds value by disclosing behavior for running jobs (returns polling guidance). However, it does not cover auth needs, rate limits, or other 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?

Two sentences; the first states the core purpose, the second adds a behavioral note and example. Front-loaded and efficient with no wasted words.

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

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

For a simple retrieval tool with two parameters and no output schema, the description covers purpose, edge case handling, and usage example. It is nearly complete, though lacking mention of response format or pagination.

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 parameter descriptions. The description adds an example but does not enhance meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool retrieves completed reference-image search results, with a specific example. It distinguishes from sibling tools like submit_reference_image_search and get_reference_image_search_status.

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

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

The description mentions that if the job is still running, it returns polling guidance, implying usage for both completed and in-progress jobs. However, it does not explicitly state when not to use or mention alternatives like get_reference_image_search_status for status checking.

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

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

No annotations are provided, so the description carries full burden. It states the tool gets 'processing status' but does not disclose possible status values, whether it's read-only, or any other behavioral traits. While adequate for a simple poll, it lacks extra context that would help an 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?

Two concise sentences: a clear statement and an example question. No unnecessary text, front-loaded with the core purpose.

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 polling tool without an output schema, the description is fairly complete. It explains the purpose and parameter. However, it could mention possible status outcomes for better completeness.

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

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

The input schema has 100% coverage with a description for job_id. The description adds an example question but no additional semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states 'Get the processing status of a reference-image search job' and provides an example question, making the purpose specific and distinct from sibling tools like submit_reference_image_search.

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 polling job status via the example, but does not explicitly state when to use this tool vs alternatives or when not to use it. No exclusions or alternatives mentioned.

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, and it discloses key behavior: the returned entity fields, the hard 180-day date cap, and the important semantic limitation that similarity is not proof of reuse. It does not cover pagination side effects or rate limits, but those are less critical for a read-only lookup as there are no destructive or auth-related behaviors to disclose.

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

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

Three short sentences: the first states the core action, the second covers output and constraints, and the third covers a caveat and alternative. Every sentence earns its place with no filler.

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

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

For a 7-parameter tool with no output schema, the description covers the main invocation requirements (required dates, range cap, input reference) and lists the returned data fields. It could elaborate on response shape and edge cases such as default game-scope behavior, but the schema covers parameters and the return-field list is sufficient for correct 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?

All seven parameters are already described in the schema, so the description need not repeat them. It reinforces the date constraint and explains that detail_url holds an opaque material_reference, but adds no parameter-level syntax beyond the schema; baseline 3 is appropriate.

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

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

The description names a specific operation ('Find visually similar creatives') on a defined resource ('a complete material_reference') and notes the mechanism (stored video-content vectors). It also explicitly disentangles this tool from get_material_reuse_clues, so an agent can distinguish it from the most closely related sibling without opening other definitions.

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 when not to rely on the tool ('Similarity does not establish reuse') and routes to the alternative get_material_reuse_clues for recorded reuse and chronology. It also flags the mandatory date range constraint, which tells an agent the tool cannot be used without a valid 180-day window.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses key operational traits: coverage start date (2025-09-15), default baseline exclusion, grouping semantics (game vs. dimension), and corrects a likely misconception (not a release date). This gives agents a solid understanding of what the tool returns and how it handles data edges.

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 entire description is three succinct sentences, front-loaded with the core purpose, followed by essential clarifications. Every sentence adds necessary information; there is no fluff or repetition. The structure leads with purpose, then caveats, then grouping options—optimal for quick agent consumption.

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

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

For an 11-parameter tool with no output schema and no annotations, the description covers essential operational context: coverage date, baseline behavior, and grouping semantics. It also clarifies the tool's scope (not release dates). While it doesn't describe the result structure, given the sibling tools and the 'find games' phrasing, the expected return is reasonably clear. Minor gaps like country selection rules are deferred to the parameter descriptions, which is acceptable.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantic value for two pivotal parameters: group_by (explains deduplication vs. original dimensions) and include_baseline (why it defaults false and the implication of including baseline day). This goes beyond the schema's basic descriptions, compensating for the potential ambiguity of these parameters.

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

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

The description clearly states the verb 'find' and the specific resource 'games first observed in official daily app-store charts' with dimensions (package, platform, country, category, rank type). It explicitly distinguishes from a release date and names the unique grouping behaviors, setting it apart from sibling tools like get_store_game_rank which focus on ranks rather than first appearance.

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 on when to use this tool (detecting first chart appearances) and explains critical usage details such as coverage start date, baseline exclusion, and grouping modes. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusion or alternative guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses the requirement for country_code, the fallback behavior, and the data returned (ranks, movement, curves, tokens). However, it does not explicitly state that the operation is read-only or mention any side effects, permissions, or rate limits. For a get-style tool, this is acceptable but not exhaustive; a 3 is appropriate.

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—two sentences—and front-loaded with the core purpose. It avoids redundancy with the schema and packs essential routing and output information into a compact space. There is no wasted verbiage.

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?

Although there is no output schema, the description explicitly lists the return data (current/best/previous ranks, movement, hourly rank curves, game tokens). It also mentions the need to consult the filter tool for valid categories and country selection, covering important prerequisites. It does not elaborate on pagination behavior, but the schema already covers limit/offset, so this is acceptable. Overall, it is complete enough for an agent to invoke correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful value beyond the schema: it highlights that country_code is mandatory and directs users to get_store_game_rank_filter for valid categories and country selection, which enriches the understanding of those parameters without repeating their 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 states a specific verb ('Get'), the resource ('official Google Play or iPhone App Store charts'), and the key parameters (free/paid/grossing, day/week/month, category). It clearly distinguishes itself from the sibling filter tool by name, leaving no ambiguity about what this tool retrieves.

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 says when to use this tool vs. the alternative: 'country_code must be explicitly specified by the user; otherwise get_store_game_rank_filter and ask for the country.' This provides clear conditional routing and names the fallback tool, which is exemplary guidance.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It discloses what is returned (valid enum-like values and the latest Google Play US free-chart date/hour), which is genuinely useful. However, it says nothing about response structure, error behavior, or whether this is a pure read operation, though the verb 'Get' and zero parameters make side effects unlikely.

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

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

Two sentences with zero wasted words. The first sentence front-loads the full list of returned value categories, and the second adds actionable usage guidance. The specific detail about the Google Play US free-chart date/hour earns its place as a concrete output highlight.

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

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

For a zero-parameter tool, invocation is trivially safe and complete. However, there is no output schema, so the description bears the full burden of explaining the response. It enumerates what kinds of values are returned but not their structure or format, which an agent would need to reliably consume the output.

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 baseline is 4 under the rubric. There is nothing for the description to explain beyond what the empty schema shows. The description appropriately focuses on output semantics instead of parameters.

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

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

States a specific verb and resource: 'Get valid platforms, rank types, periods, countries, official categories and dates for official app-store rankings.' This is clearly a metadata-discovery tool for app-store ranking queries. It distinguishes itself from ranking-query siblings by framing itself as the prerequisite discovery step, though it does not explicitly name or differentiate itself from the sibling get_filter_options, which may serve a similar discovery role.

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

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

Gives explicit usage context: 'Use before querying rankings to discover valid country and platform-specific category values.' This tells the agent when to invoke the tool relative to other ranking tools. It does not name alternative tools or state when not to use it, so it stops short of a full 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 behavioral burden. It discloses current-day realtime data availability, return contents (daily ranks, first-entry flags, optional 24-hour curves), and the package-mapping resolution behavior. It stops short of discussing rate limits or failure cases, but the core read behavior is transparent.

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

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

Three dense sentences front-load the primary purpose, then explain modes, data freshness, and return shape without redundancy. Every clause adds useful information, which is appropriate for a tool with 11 parameters.

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 schema covers all parameters and the description supplies the key behavioral logic: best/exact mode selection, package resolution, realtime inclusion, and return components. Without an output schema, a bit more detail about the exact response structure or caveats would make it fully complete, but the current combination supports correct tool 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 100%, so the baseline is 3. The description reinforces mode semantics already present in the schema (best vs exact) and summarizes outputs, but it adds little new meaning about individual parameters beyond what the schema already documents.

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

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

The description states a specific action ('Get game-level official daily chart trends') and identifies the input paths (game token or app identifier via package mapping). It also differentiates the tool's scope by explaining best vs exact modes, making it distinct from sibling tools like get_store_game_rank and get_game_trend.

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 explains how to choose between best and exact modes, and implies that game_id or package_name should be supplied, but it never explicitly names sibling alternatives or states when this tool should be preferred over them. The guidance is internal to the tool's modes rather than tool-selection 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?

There are no annotations describing side effects, persistence, or output behavior. The description says 'Record' but does not disclose whether the record is saved, transmitted, or acknowledged, nor whether the tool returns any confirmation or result. Since annotations are absent, the description carries the full burden of behavioral transparency, and it falls short.

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 tool's purpose, the condition for use, and the required input fields. It wastes no words and is easy to parse.

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

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

Given that the tool has no output schema and a simple three-parameter input, the description covers what the tool does, when to use it, and what to include. It does not explain post-submission behavior or return values, but those are not strictly necessary for an agent to invoke the tool correctly in a gap-reporting context. The description is sufficiently complete for the tool's simple nature.

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 full coverage, and each parameter description adds useful context beyond the parameter name. 'description' is clarified as 'the unmet need', 'example_query' is framed as an optional user query or scenario, and 'triggered_by_tool' is explained as the tool or scenario that exposed the gap. This gives an agent enough semantic understanding to populate the fields correctly.

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

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

The description clearly states the tool's purpose: to record an unmet analysis need. It specifies the resource ('unmet analysis need'), the intended trigger ('when existing tools cannot satisfy the request'), and the required content ('missing capability and an example query'). This is a precise and unambiguous statement of what the tool does.

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 guidance by stating that the tool should be used when existing tools cannot satisfy the request. It also instructs the user to include the missing capability and an example query. It does not explicitly name alternative tools or contrast with them, but the condition is clear enough for an agent to decide when this tool is 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 provided, the description carries the full burden of behavioral disclosure. It discloses the ordering rationale ('ordered by lifetime estimated exposure of creatives active in the last 30 days') and clarifies a semantic nuance ('This is a delivery-heat reference, not incremental exposure'), which adds important context. It does not mention safety permissions or side effects, but for a read-only resolve operation, these are less critical.

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 that are tight and front-loaded: the first gives the core action and resources; the second summarizes the output and ordering plus a clarifying caveat. 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?

Despite having no output schema, the description conveys the necessary essentials: it inputs an identifier, outputs all matching regional editions (tokens/identity), and clarifies ordering overload. It does not detail the exact response shape, but for a resolver it provides enough functional 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?

The description reinforces the identifier type ('Android package name or numeric iOS app ID') but does not go beyond the schema’s parameter descriptions. Schema coverage is 100%, so the baseline is 3 and no additional parameter semantics are provided.

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

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

The description uses a specific verb 'resolve' with clear inputs ('Android package name or numeric iOS app ID') and outputs ('game tokens and identity'), and further specifies behavior ('return all matching regional editions'). This reliably distinguishes it from sibling tools like search_games or get_game_detail, which handle different lookup patterns.

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

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

The description implies when to use the tool (when you have a platform identifier rather than a token or name) but does not explicitly contrast with any sibling tools or state when NOT to use it. There is no mention of alternatives or exclusions, so the usage context is clear 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 provided, the description carries the full burden. It discloses that the returned exposure is lifetime estimated exposure, not 30-day incremental exposure, which is a meaningful behavioral nuance. It also states the requirement to supply keyword or category. It does not disclose pagination limits or default sort behavior, but the schema covers those.

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 compact and front-loaded: the main action and scope appear in the first sentence, followed by return-value clarification and input requirements. Every sentence earns its place, and the 'not 30-day incremental exposure' clarification is valuable rather than redundant.

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 search tool with 7 optional parameters and no output schema, the description covers the core semantics: what is searched, what is returned, and the key input constraint. It does not explain the sort_by options or region semantics, but the schema covers those. The main gap is the lack of guidance on how this tool relates to sibling search tools.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a bit of meaning by explaining the keyword/category mutual exclusivity and the lifetime-vs-30-day exposure nuance, but it does not add much beyond the schema's parameter descriptions. The schema already documents defaults and allowed values.

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

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

The description states a specific verb ('Search') and resource ('mobile games'), and clarifies the scope ('across global markets'). It also names the return fields (identity, active ads, creatives, lifetime estimated exposure), which distinguishes it from sibling tools like get_game_detail or search_materials_v2. The explicit 'not 30-day incremental exposure' contrast further disambiguates its behavior.

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 usage context: supply keyword or category, and it notes that category accepts English or Chinese. It also clarifies the delivery-heat reference semantics. However, it does not explicitly state when to prefer this tool over siblings like search_materials_v2 or get_game_ads_v2, nor does it mention exclusions or 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?

No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: country means inclusion in delivery list, not exclusive targeting; exposure is global lifetime estimated, not country-specific; and metrics and material_reference must come from the same item. These go beyond what any annotation could provide. It could add pagination or limit behavior, but that is covered in the schema. This is strong for a search 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 a single concise paragraph of about 90 words. Critical usage guidance (label constraints, combination rules, country semantics, metric pairing) is front-loaded, and the pointer to get_filter_options is at the end. Every sentence adds value; there is no redundancy or fluff.

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

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

The tool has 14 parameters but zero required, and the description covers the main search semantics well: it explains label constraints, country interpretation, exposure scope, and metric pairing. The pointer to get_filter_options helps with canonical values. The output schema is absent, so the description doesn't need to explain return values. Minor gaps: no mention of date range constraints (though schema mentions 'required-date and range constraints' without specifying), and no explicit statement about sorting or pagination, but those are schema-covered.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds context beyond the schema: it clarifies that label parameters accept one canonical value each, that dimensions can be combined, and clarifies the meaning of country_code (delivery list vs exclusive) and exposure. It also warns about video_type not combining with material_type/material_types, which is not in the schema. This elevates it to a 4.

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

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

The description states a clear verb ('Search'), identifies the resource ('creatives'), and enumerates the filter dimensions (game category, creative labels, country, platform, format). It is distinct from siblings like search_materials_v2 or search_materials_by_keyword because it emphasizes filtering by labels and dimensions. However, it does not explicitly name a specific sibling it differs from, so it misses the top score by a small margin.

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 usage context: each label dimension accepts one standard value, dimensions can be combined, and it points to get_filter_options for canonical values. It also clarifies country semantics (delivery list vs exclusive targeting) and warns about combining video_type with material_type/material_types. However, it does not explicitly state when NOT to use this tool versus alternatives like search_materials_v2 or search_materials_by_keyword, so it stops short of a 5.

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

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

With no annotations, the description carries the burden and covers return behavior ('opaque material references and direct video addresses'), validation ('Keyword length is 2-200 characters'), and the core behavioral trait that it is text matching, not vector search. It does not mention error cases or pagination behavior, but the schema covers limit/offset and the operation is clearly read-only by nature.

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?

Five short sentences, front-loaded with the core action and scope, then return info, constraint, and alternative. No filler; every sentence contributes a distinct piece of information even if the length constraint repeats the schema.

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 gives the essential behavior, return type, constraint, and routing to the alternative. It could be slightly more specific about how opaque material references should be consumed, but it is otherwise complete enough for correct 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 100%, so the baseline is 3. The description adds semantic context for the keyword parameter (text matching, not vector search) and summarizes optional game/date filters, but it does not significantly elaborate on the remaining parameters beyond what the schema already documents.

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

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

States a specific verb and resource ('Search creative copy and labels by keyword') plus optional game/date scope. Explicitly distinguishes itself from search_materials_v2 and from visual-description vector search, so an agent can tell it apart from siblings.

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

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

Provides an explicit alternative: 'Use search_materials_v2 with query for bilingual concept expansion.' Also sets a when-not boundary with 'This performs text matching, not arbitrary visual-description vector search,' so the agent knows not to use it for visual queries.

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 reveals a critical nuance: counts are attributions, not deduplicated totals, because creatives/plans can cover multiple countries/platforms. It also notes the 'Return aggregates only' scope. It does not cover output format or error handling, but the key counting behavior that could mislead an agent is clearly explained.

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 sentences, each earning its place: the first states purpose, the second clarifies attribution semantics, and the third gives usage conditions plus the sibling alternative. Information is front-loaded and there is no filler.

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

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

For an 18-parameter tool with no output schema, the description covers the core purpose, the counting semantics, required filter constraints, and the primary alternative. It does not mention pagination, limits, or the result shape, but those are secondary given that the schema fully documents parameters and no output schema exists. The essential decision-making info for an agent is present.

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 the grouping dimension (platform and country) and mentions the need for at least one filter, but it does not elaborate on any specific parameter beyond what the schema already documents. The vague 'creative-label filter' does not map cleanly to a schema parameter, adding little value.

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 the verb 'Aggregate' and a specific resource ('ad-plan and creative counts/shares') grouped by 'delivery platform and country'. It explicitly contrasts with get_game_platform_stats for deduplicated totals, which distinguishes it from a key sibling without needing to inspect schemas.

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 states exactly when to use the alternative ('Use get_game_platform_stats for single-game/platform deduplicated totals') and enumerates the required conditions for calling this tool: explicit dates (max 180 days) and at least one of the listed filters. This leaves no ambiguity about prerequisite inputs.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses several non-obvious behaviors: results have atomically associated material_reference without standalone IDs, exposure is global lifetime estimated exposure (not country-specific), pagination reports has_more rather than an exact total, and query uses concept matching rather than exact text matching. It also warns against repeated paging. This is strong behavioral transparency, though it doesn't cover every edge case (e.g., error behavior, rate limits).

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

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

The description is dense but well-organized: it front-loads the core purpose, then packs critical behavioral caveats into compact sentences. Every sentence earns its place — the country_match semantics, exposure scope, pagination behavior, and the explicit exclusion of visual-description search are all high-value. It's slightly long, but given 21 parameters and no annotations, the density is justified.

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 21-parameter search tool with no annotations and no output schema, the description covers the most important contextual gaps: result identity model, pagination semantics, exposure scope, country matching semantics, and the unsupported search type. It doesn't describe the return shape in detail, but with no output schema and a complex tool, the description does a solid job of covering what an agent needs to know to call it correctly. Minor gaps remain around error cases and rate limits.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantic context beyond the schema: it explains that country_match 'contains' matches any country while 'exclusive' requires exact set equality, clarifies that exposure is global lifetime estimated exposure, and notes that query uses concept matching expanded to Chinese source labels. It also warns that video_type is mutually exclusive with material_type/material_types. This goes beyond the schema's per-parameter 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 opens with a specific verb ('Discover') and enumerates the full set of filter dimensions (games, countries, platforms, formats, languages, aspect ratio, duration, device, quality, discovery dates), which clearly distinguishes it from sibling search tools. It also explicitly states what results contain (material_reference, no standalone creative/ad IDs), further differentiating it from tools like get_material_detail_v2 or search_materials_by_filter.

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 routing guidance: use get_game_platform_stats for totals instead of repeated paging, and states that arbitrary visual-description semantic search is not supported (which routes away from this tool for that use case). It also clarifies country_match semantics (contains vs exclusive) and pagination behavior (has_more, not exact total), giving an agent clear conditions for when and how to use this tool.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explains that the job is asynchronous, lists possible error types (IMAGE_FETCH_FAILED, INVALID_IMAGE, EMBEDDING_MODEL_ERROR), and describes genre normalization and visual-only fallback behavior. Missing details like expected latency or polling mechanism, but sufficient for understanding key 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 paragraph of four sentences, front-loading the main action and usage context. Every sentence adds value: purpose, usage condition, constraints/failures, and special behavior (fallback). 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 (async job, multiple failure modes, genre normalization) and no output schema, the description provides sufficient context. It covers input requirements, processing behavior, and fallback logic. It could mention how to retrieve results (sibling tools) but is otherwise complete for a submission tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema by explaining async processing, failure modes, and fallback behavior. It does not expand on individual parameters beyond what the schema already provides, but enhances overall understanding of parameter usage.

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 ('Submit a reference-image similarity search') and the resource (asynchronous job). It distinguishes itself from sibling tools like 'get_reference_image_search_results' and 'get_reference_image_search_status' by specifying it is the submission step.

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

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

The description provides explicit conditions for use: 'when the user provides a directly downloadable public HTTPS image URL.' It also states what is not supported (HTML pages, local paths, base64). However, it does not mention when to use alternatives like 'find_similar_creatives' or when to avoid this tool.

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