Versusbrief

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, and the trailing 'Read-only' merely restates them. The 'Free, 0 credits' note adds a little value about cost/credits behavior, but permissions, error behavior, and freshness are unspecified – acceptable with annotations carrying the safety profile.

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

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

Very short and front-loaded with the returned fields. It is telegraphic rather than prose, and 'Free, 0 credits' is cryptic without context, but no sentence is wasted.

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 helpfully lists the return contents, and annotations cover the safety profile. A no-arg read-only status tool is adequately specified; only the ambiguous credits phrasing 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?

Zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. The schema is empty and fully covered.

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 enumerates the exact payload (plan, credits left, brands used vs cap, renewal timing, plans page), which lets an agent tell this is an account-and-billing status read. It lacks a clear verb like 'Get', but the resource and returned fields are unambiguous, and no sibling covers the same ground.

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

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

There is no when-to-use statement or prerequisite. The sibling tools are unrelated (ads, keywords, audits), so there is little to differentiate, but the description still gives no trigger condition for calling it versus simply ignoring it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description's 'Read-only' merely restates it. However, '1 credit' discloses a per-call cost that annotations cannot convey and that materially affects an agent's budget decisions. It stops short of explaining when credits are charged or whether results are cached/sampled.

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 terse fragments front-load the returned metrics, then cost, then safety - no filler, no padding. The trailing 'Read-only' is redundant with the readOnlyHint annotation and is the one line that does not earn 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 single-purpose, two-parameter metric tool with no output schema, the description does state the shape of the return (the three metrics) and the cost and safety profile. It is nearly sufficient; an explicit note on what DataForSEO rank measures or on failure behavior when a competitor domain is invalid would close the remaining gap.

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

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

Schema description coverage is 100%: the schema already explains that 'brand' defaults to the account brand and that 'competitor' is a domain like competitor.com. The description adds nothing about either parameter, so the baseline 3 applies since the schema carries the full burden.

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 metrics returned (referring domains, backlink count, DataForSEO rank on a 0-1,000 scale), so an agent knows precisely what data this tool delivers. It is a noun phrase rather than a verb+resource, and it offers no explicit differentiation, but no sibling tool overlaps this backlink domain, so ambiguity is low.

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

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

There is no statement of when to call this tool versus alternatives, no prerequisite or ordering guidance, and no mention of what kind of task it serves (competitor analysis, SEO audit, etc.). Only the cost note hints at usage trade-offs; the agent must infer the context itself.

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 read-only, non-destructive, open-world behavior, and the description reinforces 'Read-only'. Beyond that it adds real behavioral context: the 1-credit cost and the variable return shape ('Ad text when Google returns it; otherwise format, dates and a preview link'), which the annotations do not cover.

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?

Compact and front-loaded: scope, source, return behavior, cost, and safety in a handful of clauses. Slightly telegraphic phrasing costs a bit of readability but nothing is wasted.

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

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

With no output schema, the description usefully sketches the return shape (ad text or fallback fields plus preview link) and discloses the credit cost. Missing only guidance on the brand-cap implication of the brand parameter and when to prefer the Meta sibling.

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 restates the domain/brand/country inputs but adds no syntax, default, or format detail 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+resource: ads from Google Ads Transparency for a domain/brand in one country. The platform is named ('Google Ads Transparency'), which implicitly separates it from the sibling competitor_ads_meta, though the differentiation is not spelled out.

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

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

No explicit when/when-not or prerequisite guidance. Usage is only implied by the source named ('Google Ads Transparency') versus the sibling competitor_ads_meta, which an agent must infer covers a different ad network.

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 cover the safety profile (readOnlyHint, destructiveHint=false), so the description is not burdened there. It adds genuinely useful behavior: a cap of 6 distinct ads, an EU/UK-only scope that the result self-reports, filtering of unrelated pages, and a 1-credit cost. Those extras are not in the structured fields.

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

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

Front-loads the core action and cap, then the constraints, then cost. Mostly tight, though 'and the result says so' is slightly loose phrasing and the filtering clause is dense.

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 carries the return-value burden and does so reasonably: it discloses the 6-ad cap and that unrelated pages are named but not shown. Credit cost and platform scope round it out, leaving only minor gaps like ad record fields.

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

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

Schema coverage is 100%, so the schema already documents brand, country, and competitor. The description's 'brand-name search' and EU/UK notes add marginal framing but no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Active ads from the official Meta Ad Library API') and pins the platform, which naturally separates it from the sibling competitor_ads_google. An agent can tell what it fetches and from where without opening the schema.

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

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

Gives an applicability constraint ('EU/UK delivery only') and notes it is a brand-name search, but never states when to pick this over competitor_ads_google or what happens outside EU/UK. Usage is implied rather than guided.

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 read-only, non-destructive, open-world behavior, so the bar is lower; the description still reinforces 'Read-only'/'Does not publish' and adds genuinely new operational context: a cost of '1 credit' and the fact that output is constrained 'inside platform limits'. It does not cover error behavior or what happens when the brief is too long.

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 clipped sentences, each carrying distinct information (output counts, competitor rule, no-publish boundary, cost), with the most important content front-loaded. The parenthetical character counts ('5 headlines (30)') are compact but slightly cryptic on first read.

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 correctly takes on the job of describing the return shape (counts and platform limits per asset type), and it flags cost and side-effect status. Missing only minor detail such as language/tone handling or what happens if the brief is unusable.

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

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

Schema coverage is 80%, so most parameters are already documented; the description nonetheless adds semantics for the competitor parameter (name must never appear) and confirms the brief is the sole required input. Only 'brief' remains undescribed in either place, which is minor for a self-evident required field.

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?

Names a specific verb+resource (drafts ad variants) and quantifies exactly what is produced: 5 headlines, 2 descriptions, 1 Meta primary text, from a brief. It implicitly separates itself from the fetch-oriented siblings (competitor_ads_google/meta) by framing this as generation rather than retrieval, though it never names an alternative.

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

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

Gives explicit conditions for one input ('Pass competitor to make sure its name never appears') and a clear negative boundary ('Does not publish'), which implies you need a different tool to publish. It never names that alternative or states when to pick this over sibling drafting/export tools, so 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=true and destructiveHint=false, and the description reinforces this with 'Does not write to an ad account.' Beyond annotations it adds genuinely useful context: the credit cost (1 credit), validation behavior (character limits, final-URL https check), and that the return value is a file link. It does not contradict any annotation.

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?

Dense, front-loaded telegraphic sentences with essentially no filler; the output formats lead and constraints follow. The clipped fragments make it slightly harder to parse than a flowing sentence would be, but 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?

With no output schema, the description correctly compensates by stating 'Returns a file link,' and it covers cost, safety, and validation. But for a 7-parameter tool at 14% schema coverage it leaves most input semantics unspecified, so it is adequate rather than complete.

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

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

Schema description coverage is only 14% (only 'brand' is documented), so the description must carry the burden for the other six parameters, and it largely does not. It only obliquely references finalUrl (the https check) and target (Google vs Meta); headlines, descriptions, campaign, and adGroup semantics go unaddressed.

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 the concrete deliverable precisely: a Google Ads Editor CSV (responsive search ad, paused) or a Meta bulk-import sheet (paused), naming both output variants keyed to the target enum. It is clearly a draft-generation/export tool, though it doesn't explicitly contrast itself with the nearest sibling (draft_ad_variants).

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

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

Usage is implied by the artifact types (you use this to produce an import file for Google or Meta), and the parenthetical 'paused' plus https/character checks hint at pre-launch drafting. However, there is no explicit when-to-use guidance vs draft_ad_variants or any exclusion criteria.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint, destructiveHint), so the bar is lower. The description still adds real value by disclosing the credit cost ('1 credit') and the returned fields (position, volume, CPC in USD), which annotations do not carry.

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

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

A single front-loaded sentence carries the resource, scope, returned metrics, cost, and safety in minimal words. No filler, no restating of the name.

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

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

There is no output schema, so the description correctly describes what is returned (keywords with position, volume, CPC). Combined with complete parameter documentation and full annotations, an agent has enough to call it correctly; only the lack of explicit sibling routing keeps it short of a 5.

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

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

Schema description coverage is 100%, and the schema fully documents brand, country, and competitor (including default brand and default GB country behavior). The description adds no parameter-level syntax or defaults, so the baseline 3 applies.

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

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

States a specific resource and verb-equivalent ('competitor's biggest non-brand organic keywords') and enumerates the returned metrics, so the agent knows exactly what it gets. It implicitly separates itself from the ads siblings via 'non-brand organic,' but does not explicitly name a sibling the way the calibrating high example 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 gives no when-to-use guidance, no prerequisites, and no named alternatives. It does not say how this differs from serp_snapshot or competitor_ads_* beyond the implicit 'organic keywords' framing, leaving routing entirely to inference.

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

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

Annotations already cover read-only/non-destructive/open-world, so the bar is lower, and the description still adds two genuinely useful traits: the 1-credit cost and the degradation path when a site blocks automated readers (PageSpeed still runs, result flags the page as not read). It does not say whether the call is synchronous or how long a PageSpeed run takes, which is the remaining behavioral gap.

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

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

Three tight sentences, front-loaded with the deliverables, followed by the failure-mode caveat and the cost. The long pixel parenthetical is dense but every clause carries information an agent needs; 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 carries the return-value burden and does so by enumerating the data categories returned, plus the blocked-page outcome and cost. It does not mention device/viewport context for the PageSpeed score or expected latency, but for a 2-parameter read tool this is close to complete.

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

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

Schema description coverage is 100%, so both 'brand' and 'competitor' are already documented with examples and semantics. The description adds no parameter-level detail beyond the schema, so baseline 3 applies.

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

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

The description names a specific verb+resource ('audit the competitor's home page') and enumerates exactly what it extracts: PageSpeed scores, LCP, headline, CTAs, forms, and a specific list of tracking pixels. It is clearly distinguishable from siblings like teardown or serp_snapshot without opening any schema.

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

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

Usage is implied by naming 'the competitor's home page' as the target and by the 1-credit cost note, but the description never states when to pick this over teardown, competitor_ads_google, or other audit-adjacent siblings, nor any prerequisites such as needing the competitor to have a live site.

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 'Read-only' merely repeats structured data. The genuinely additive item is 'Free, 0 credits,' which discloses cost behavior an agent cannot see in the annotations, but nothing is said about result count, ordering guarantees, or defaults.

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 fragments, front-loaded with the resource and its URLs, then cost, then safety. Nothing is padded, though the fragmentary style omits any connective guidance that could have earned its place.

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

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

With no output schema, the description does cover the return shape (reports/teardowns with URLs), and annotations cover safety. However, for a paginated list tool the missing default limit, result count, and auth expectations leave real 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 0% for the single 'limit' parameter (max 50, no default documented). 'Your most recent' weakly implies recency ordering, but the description never explains the limit, its default, or the 50 cap, so it fails to compensate for the schema gap.

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

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

The description names the concrete resource returned: the user's most recent pitch reports and teardowns, including their URLs. That is specific enough to distinguish a listing tool from the sibling creation tools pitch_report and teardown, though the verb 'list' is only implied rather than stated.

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

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

'Your most recent' implies retrieval of previously generated reports, which hints at when to use it, but there is no explicit when-to-use statement and no sibling is named as an alternative. The agent must infer that this is the read counterpart to pitch_report/teardown.

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?

Despite annotations covering safety, the description adds substantial behavior: 60 credits charged only when the prospect and at least 2 rivals have data, prospects never take a brand slot, Meta ads limited to EU/UK, and Pro/Agency branding on the output. These are real operational facts not derivable from readOnly/openWorld hints.

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

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

Purpose is front-loaded and every sentence carries operational detail, but the middle is a dense run-on list of comparison dimensions that could be tightened. Still, no sentence is pure 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?

With no output schema, the description does the work of explaining the return ('a client-ready page') and what it contains (map pack/search position, 90-day plan, draft ads). For a complex 8-param tool it covers purpose, cost, and output adequately.

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

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

Schema description coverage is 100%, so all 8 parameters are already documented. The description only adds a little (Meta ads EU/UK scope, country default), which merely echoes the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('pitch report' for winning a new client) plus exact scope: prospect against up to 3 local rivals from Google's map pack. It enumerates the comparison dimensions and deliverables, clearly distinguishing it from siblings like teardown or serp_snapshot.

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 opening clause 'For winning a new client' gives clear intended context, and it explains that rivals and keyword can be passed or auto-picked. It doesn't explicitly say when a sibling (e.g. teardown) would be preferable, so no exclusions are stated.

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 establish read-only safety, but the description adds real behavioral context beyond them: the privacy guarantee that author name, photo and profile are never stored, the cost of 1 credit, and the silent-empty-result edge case when the matched Google place does not match the domain. That mismatch behavior is exactly the kind of hidden trait an agent needs.

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

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

Three tight sentences, front-loaded with the returned data, followed by privacy, fallback and cost. Nothing is padded, though 'Read-only' mildly restates an existing annotation and could be dropped.

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 the burden of describing returns and does so concretely (rating, count, themes, quotes). Privacy, cost and the mismatch edge case are covered; only the absence of guidance on result volume or empty-result behavior for a well-matched place 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?

Schema coverage is 100%, so the baseline is 3. The description goes further by explaining the rationale for business_name (the domain-to-place mismatch case), turning an optional string into a meaningful recovery parameter. City, brand and country semantics are left entirely to 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 names the exact resource and return payload: rating, review count, themes and short quotes from public Google reviews. That is specific enough to separate it from every sibling (ads, backlinks, SERP, teardown), though the verb 'get/retrieve' is only implied rather than stated.

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

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

It gives one concrete conditional instruction — if the Google place found does not match the domain, reviews are not returned, so pass business_name — which is genuinely actionable. However, there is no guidance on when to choose this tool over siblings or when reviews are not the right signal, so 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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description's genuine additions are the per-call cost ('1 credit') and the single-keyword/single-country constraint, which hint at a one-shot rather than batch operation, but return format and result limits remain undisclosed.

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

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

Three short fragments with no filler; cost is placed early and the scope constraint is front-loaded. Slightly telegraphic, but nothing wasted.

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 snapshot tool with no output schema, the description usefully summarizes the return content (organic results + local pack) and cost, but says nothing about result volume, pagination, or device/locale handling that an agent may need.

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

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

Schema description coverage is 67%, so the schema already explains brand and country in detail. The description reinforces that keyword and country are singular ('one keyword in one country') but adds nothing about format or syntax beyond the schema.

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

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

States a specific resource: Google organic results plus the local pack, scoped to one keyword and one country. It is clear what the tool returns, though it does not name or contrast a sibling (e.g. keywords_for_domain or teardown) that could plausibly overlap.

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

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

There is no when-to-use guidance: no condition for selecting this over keywords_for_domain, teardown, or competitor_ads_google, and no mention of prerequisites. The '1 credit' note is a cost disclosure, not usage 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?

Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds materially more: a 20-credit cost that is only charged when at least 3 of 6 data sources respond, the EU/UK restriction on Meta commercial ads, and the privacy handling of review themes (no author names). It also states the return shape (findings plus a shareable report URL), which no structured field provides.

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

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

Two sentences, front-loaded with the scope statement followed by the output/cost contract; the long enumeration is justified because it defines what the bundle actually delivers. Slightly list-heavy but no wasted sentences.

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 multi-source aggregation tool with no output schema, the description discloses scope, cost gating, source limitations, privacy handling, and the returned report URL. It stops short of stating runtime expectations, partial-failure behavior below the 3-source threshold, or whether the report URL expires, which would be the last pieces an agent needs.

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

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

Schema description coverage is 100%, so all six parameters (including brand cap semantics and the client_domain drafting rule) are already documented in the schema. The description only echoes a couple of those constraints (EU/UK Meta ads, no competitor mention in drafts) rather than adding new per-parameter meaning, so the baseline 3 applies.

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

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

The opening clause 'One competitor in one call' names the verb and resource precisely and enumerates the aggregated artifacts (keywords, Meta/Google ads, SERP, reviews, landing page, backlinks, drafts, summary), which cleanly separates it from the granular siblings like competitor_ads_meta and serp_snapshot. An agent can tell this is the orchestrating bundle without opening any schema.

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

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

'One competitor in one call' implies this is the single-call alternative to invoking the individual sibling tools, and the credit-gating rule plus 'EU/UK only' constraint set clear expectations. However, it never explicitly says 'use this instead of calling keywords_for_domain + competitor_ads_meta separately' or when a narrow sibling is preferable, so the routing guidance is implied rather than stated.

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