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=true, destructiveHint=false and openWorldHint=false, and the description's 'Read-only' merely restates that. The one genuinely additive fact is the cost model ('Free, 0 credits'), which annotations cannot express, but pagination/ordering behavior and result shape are left unstated.

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, no filler, and the resource is front-loaded. Slightly telegraphic to the point of omitting useful detail, but nothing wasteful.

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 mention of URLs gives partial return-value context despite there being no output schema, and the cost note is helpful. However, for a list tool with an undocumented pagination parameter, the description leaves the agent guessing about the result shape and limit semantics.

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 0% and the single 'limit' parameter (1-50) is undocumented in both schema and description. 'Your most recent' hints at a recency ordering but never explains what limit controls or its default.

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: listing the caller's most recent teardown reports, including their URLs. It implicitly distinguishes itself from the sibling 'teardown' (which presumably generates a report), though it never names that relationship explicitly.

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

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

No explicit when-to-use or when-not-to-use guidance. The agent can infer you call this to retrieve reports after running a teardown, but the description never says so or contrasts it with any sibling 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?

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 read-only safety profile, and the description layers on substantial non-obvious behavior: credit cost and the 3-of-6-source charging threshold, EU/UK-only Meta ads, reviews stripped of author names, and drafts written for the client that never mention the competitor. This is behavior an agent cannot get from the annotations or 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?

Two sentences, front-loaded with the core purpose and ending with the most decision-relevant facts (cost rule, read-only). The middle enumeration is long but each item is a distinct data source that earns its place, so it stays efficient without waste.

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 closes that gap by stating what comes back ('the findings plus a shareable report URL'). Combined with the cost rule and read-only note, an agent has everything needed to decide and call correctly.

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

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

Schema description coverage is 100%, so every parameter is already documented, establishing a 3 baseline. The description's detail (EU/UK Meta scope, client-oriented drafts) largely restates what the schema already says for country and client_domain, so it adds little beyond the structured fields.

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 ('One competitor in one call') and enumerates the concrete outputs (keywords, Meta/Google ads, SERP, review themes, landing page, backlinks, drafts, summary). This clearly distinguishes it from the many single-source siblings like competitor_ads_meta or keywords_for_domain.

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 context is clear: all-in-one per-competitor research with a stated billing rule ('20 credits, charged only when at least 3 of the 6 data sources answer') that helps an agent judge cost. It does not, however, explicitly tell the agent when to prefer the narrower siblings instead, so it stops short of 5.

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