distribution

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description contributes that version and version history are returned, which is useful added context, but says nothing about authentication, workspace scoping behavior, or whether the context can be stale.

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

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

A single dense sentence that front-loads the resource and its contents, with only minor redundancy in 'its version and the version history'. No filler 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 one-parameter read tool with no output schema, the description covers the returned fields (name, summary, audience, version, history) well enough to set expectations. It stops short of describing the shape of the version history or how the context is scoped, but nothing critical for invocation is 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?

Schema description coverage is 100% and the single enum parameter is fully documented in the schema ('Leave out for the whole context'). The description's 'Optionally one section' merely restates the schema, adding no format or semantic detail beyond it, 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 ('company context') and enumerates its parts (name, summary, audience) plus version/version history, so an agent knows what comes back. It gives no differentiation from siblings such as resolve_audience, which retrieves overlapping audience data.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of alternatives (e.g., resolve_audience) even though a sibling covers similar audience territory. The only conditional, 'Optionally one section,' is a parameter note rather than 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?

Annotations declare a non-read-only, non-destructive, non-idempotent write. The description adds substantial context beyond them: the report is queued and retried on failure, the return is the feedback id, identical reports within 15 minutes return the earlier id with duplicate true and are not re-sent, and there is a 20-per-brand-per-hour cap. It also states data-handling limits (identifiers only, context keys silently dropped), though it does not spell out permission or auth requirements.

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 but front-loaded: the core action and its triggers come first, then data-handling limits, then return and rate-limit behavior. It is long and slightly repetitive with the schema wording, but virtually every sentence carries operational information rather than 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 correctly supplies the return contract (feedback id, duplicate true on dedup) plus delivery, retry and rate-limit behavior. Nothing an agent needs to call this tool correctly and interpret its response is 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?

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: context accepts only tool, request_id, url, error_code and status with anything else dropped, and details should carry what happened, how to repeat it and what was expected using identifiers only. That goes beyond the schema's field-level docs.

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: reporting a problem or idea to the distribution team, with the exact content required (kind, one-line title, details). It is unmistakably distinct from siblings like inventory, guest_status or resolve_audience, so an agent can route to it 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?

Explicit when-to-use with concrete triggers (a call failing unexpectedly, an empty or wrong field, a missing capability, user frustration or an idea) and explicit when-not conditions (missing scope, mandate refusal, rate limit). It also instructs the agent not to ask the user first, removing ambiguity about autonomy.

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 readOnly, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description still adds real value by disclosing the authentication requirement ('with a key' vs. without) and enumerating what the response covers (available tools, gated tools, sign-in/claim path), which goes beyond the structured 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?

It is short and front-loads the key fact ('No account needed'), and every clause describes part of the result set. The run-on list in the second sentence is a little disorganized but wastes no sentences on 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?

There is no output schema, so the description must carry the return-value burden, and it does by naming the three things reported: currently answering tools, tools needing an account, and the claim/sign-in location. Combined with annotations covering safety, an agent has enough to call it correctly, though the wording could be tighter.

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 is nothing for the description to disambiguate; per the rubric a 0-parameter tool baselines at 4. The description correctly implies no input is required.

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 conveys the resource (what an unauthenticated/guest connection can access) but never states a clear verb such as 'reports' or 'lists'; it opens with a fragment ('No account needed') and ends in a garbled clause ('and claim, where to sign in'). An agent can infer the purpose, but the muddled phrasing makes it less than fully clear, and no sibling tool is referenced.

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 account needed' implies the tool is callable before authentication, which hints at when it applies. However, there is no explicit statement of when to use this versus the siblings (brain_get, inventory, plan_quote_guest) or of any exclusions, so the guidance remains 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?

Annotations already declare this a read-only, idempotent, non-destructive, closed-world operation. The description adds genuinely useful context beyond that: it is count-only, never exposes creator identity (a privacy guarantee), is scoped to approved creators and posts currently on sale, and classifies coverage as strong or thin.

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

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

A single sentence that front-loads the core meaning (network reach to your own audience, per channel) and appends the key qualifier (counts only, no identity). It is dense and a little run-on, but there is no wasted sentence.

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 input parameters and no output schema, the description has to carry the return semantics, and it does reasonably: per-channel counts, a strong/thin coverage signal, and an explicit privacy constraint. The exact shape of the result (e.g., what a channel entry looks like) remains unspecified, which keeps it from 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?

The tool takes zero parameters, so the baseline for this dimension is 4. Nothing in the description is needed to disambiguate inputs, and it does not introduce any confusing parameter-like language.

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 explains that this reports how well the network reaches your own audience, per channel, as counts, which is a coherent resource. However, it never states a verb ("returns", "reports") and the name/title mismatch ("inventory" vs "Network coverage") plus the lack of any contrast with siblings like resolve_audience leaves the exact purpose somewhat vague.

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 prerequisites, and no mention of alternatives. The closest sibling, resolve_audience, is not referenced even though both concern audience reach, leaving the agent to guess which to call.

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/idempotent/non-destructive safety, but the description adds genuinely useful context beyond them: no authentication required, the response is a range (not a commitment), and it reports how many creators sell the format and when the data was read. That freshness/coverage disclosure is exactly the kind of behavioral detail annotations cannot express.

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?

'No account needed' is well front-loaded, but the core sentence is a long run-on that buries the subject ('The all-in price range ... and that range times the number of posts ... with how many creators ...') and forces re-reading. The plan-vs-range caveat is useful but the overall packaging is dense rather than economical.

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 takes on the burden of describing the return: price range, creator count, and read timestamp. It also covers the auth model and the range/plan distinction. The only gap is that it never states a currency or unit for the range, leaving the numeric output under-specified.

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, but the description adds interpretation: 'posts' scales the per-post range (the range times the number of posts) and the format options are glossed as original post, quote repost, or thread. This explains how the two parameters combine to form the result, which the schema alone does not.

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 concretely defines the output: an all-in price range a brand pays per post in a given format, multiplied by the number of posts, plus creator count and data recency. It also cleanly distinguishes itself from a real 'plan' (which names creators and dates). The verb itself is implicit (the title says 'Estimate'), making it slightly less crisp than a 5, but the resource and scope are unmistakable.

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 account needed' states the key usage precondition for this guest tool and contrasts it with a plan that requires an account/key. However, it never routes the agent among the actual siblings (inventory, resolve_audience, guest_status) or explains when to reach for a guest estimate versus an authenticated plan. Usage is implied rather than spelled out.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds that this is a lookup returning matched segments and coverage, and that it mirrors campaign-start behavior, but does not add richer traits such as latency or scoping 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?

Two compact sentences, front-loaded with the outcome and modes; the parenthetical labels efficiently tie inputs to modes. 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 read-only, idempotent lookup with no output schema, the description usefully describes the return content (segments plus coverage per channel), which compensates for the absent output schema. Remaining gaps are minor.

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 restates the parameter roles (intent_id, product, audience, geography) and the campaign-vs-profile dichotomy, which the schema already documents, adding no new syntax or constraint details.

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

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

The description names the resource (audience fit) and its two input modes (campaign intent_id vs. described profile) and states what it returns (audience segments and per-channel coverage). It is a clear noun-phrase statement rather than a crisp verb, but an agent can tell what it produces.

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 distinguishes the two invocation paths — supply intent_id for an existing campaign, or supply product/audience/geography to describe a profile — and frames it as 'the same check a campaign gets when it starts.' It gives no when-not guidance or named alternatives, but the context is clear.

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