AdRadar

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

Annotations already declare readOnly, idempotent and non-destructive behavior, so the safety profile is covered. The description adds two pieces of context not in the structured data: the balance is scoped to 'the connected API key' and the call costs no credits ('Free'), both relevant to an agent's decisions.

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 terse sentences, front-loaded with the action and resource, with zero wasted words. The cost note is brief and 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 trivial parameterless read tool whose annotations already cover safety, the description is nearly complete. It does not describe the shape of the returned balance value, but with no output schema and such a simple operation this is 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?

The tool takes zero parameters, so there are no parameter semantics to document; the baseline for a parameterless tool applies. The description correctly implies no arguments are 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?

States a specific verb ('Show') and resource ('remaining AdRadar credits'), which is immediately distinguishable from the sibling tools (evaluate, spy, tiktok_top) that all perform analysis rather than account checks. The purpose is clear, though it does not explicitly name a sibling it is not.

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 'Free' note implies this is a safe pre-check to run before paid operations, but the description never states when to use it versus alternatives or any prerequisite context. Usage is only 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?

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description usefully adds that the call costs 1 credit and does not scrape, but it says nothing about the shape of the classification result or latency, leaving the behavioral picture 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 short sentences with no filler, and the core action is front-loaded ahead of the billing note. Every clause 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?

There is no output schema, so the description should characterize the return value, yet '10-dimension matrix' is never explained in terms of output format or per-dimension scoring. Credit cost is disclosed, but an agent still lacks a picture of what comes back.

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

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

Schema description coverage is 0% for the single parameter, so the description carries the burden; 'raw ad copy' implies pasted text (as opposed to a URL), which is useful. However, it omits the 2000-character cap enforced by the schema and any format expectations, so it only partially compensates.

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 ('Classify'), a clear resource ('raw ad copy'), and the framework applied ('Jev's 10-dimension marketing matrix'), which distinguishes it from siblings like ad_radar_spy and ad_radar_tiktok_top. It is clear what the tool does, though it does not explicitly name the siblings it is not.

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

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

The phrase 'without scraping' implies you feed raw copy rather than a URL, but there is no explicit when-to-use guidance, no comparison to siblings such as ad_radar_spy, and no prerequisites stated. Usage must be inferred rather than read.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral fact the annotations lack: 'Costs 1 credit per call'. It stops short of explaining non-idempotency or result variability across repeated calls.

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

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

Two tight sentences, purpose front-loaded with the cost caveat trailing. 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?

There is no output schema, so the description carries some burden for explaining what comes back; it hints at scored signals/hooks/angles but not the shape or per-ad granularity. Cost and purpose are covered, making it minimally adequate but not rich.

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 60% schema description coverage, the description is expected to compensate, but it only restates 'keywords' which the schema already documents well. The undocumented parameters (max_queries, active_status) receive no explanation of defaults, limits, or semantics from the prose.

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 ('Scrape public Meta Ad Library by keywords') plus the value-add ('score winning signals, hooks and angles'). The Meta-specific framing cleanly separates it from sibling ad_radar_tiktok_top and from the balance/evaluate utilities.

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

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

Usage is implied by the keyword-search framing, but there is no explicit when-to-use or when-not guidance and no routing to siblings such as ad_radar_evaluate or ad_radar_tiktok_top. An agent must infer the platform boundary on its own.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-redundant context: the fixed result count (20) and the credit cost (1 credit), which is a real operational constraint an agent should weigh before calling.

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

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

One sentence, front-loaded with the resource and source, then the return payload, then the cost. Every clause carries information; nothing is padding.

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

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

With no output schema, the description does cover the return shape (fields, count), which is the right call. However, for a tool whose two enum parameters are undocumented in both the schema and the description, the definition is incomplete on the input side.

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 33% — only 'country' is documented in the schema, and the two enum parameters (period, order_by) carry no explanation of what 7/30/180 or for_you/ctr/like mean. The description mentions 'for a country' but adds no semantics for period, order_by, or their defaults, so it fails to compensate for the coverage gap.

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

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

States a specific resource and source ('Top TikTok auction ads from TikTok Creative Center') plus the payload shape (20 ads with CTR, likes, budget tier, objective, video URL), so the agent knows exactly what comes back. It does not explicitly distinguish itself from the siblings (ad_radar_spy in particular could sound similar), so it stops short of a 5.

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

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

Only 'Costs 1 credit' is offered as guidance; there is no when-to-use, when-not-to-use, or pointer to an alternative such as ad_radar_spy for competitor research. The agent must infer usage entirely from the name.

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