CreatorScore

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context by clarifying that it is free and only surfaces a purchase link rather than charging — preempting the natural assumption that a 'buy' tool spends money.

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

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

Three short sentences: what it returns, when to call it, and the key caveat. The most decision-relevant information is front-loaded and nothing is redundant.

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

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

For a zero-parameter, read-only tool with no output schema, the definition covers purpose, triggers, and the no-charge guarantee. Minor gaps (currency, whether links expire, pack sku format) are low stakes but not fully covered.

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

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

There are zero parameters, so the baseline is 4. The description instead characterizes the response content (balance, packs, prices, buy link), which is helpful given no output schema is defined.

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?

Uses a concrete verb chain ('Show balance + available credit packs with prices + a link to buy') that tells the agent exactly what comes back, distinguishing it from siblings like check_account. The wording is telegraphic rather than prose, but the resource and output are unambiguous.

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

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

Gives two explicit trigger conditions: a score/vet failing for insufficient credits, or the user asking to top up. It does not name a sibling alternative or state when not to use it, which keeps it below a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds genuinely new behavioral context beyond them: it is free/zero-credit, performs no scraping or scoring, and is pure math over caller inputs — important for an agent deciding whether to call it casually. It also previews the return structure (band plus breakdown, package total plus per-line output) despite there being no output 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?

A single dense paragraph that leads with the core computation and result shape, then the minimal call, then the package mode — a sensible front-loading. The LinkedIn-impressions caveat is restated both for the primary medianViews and inside the package guidance, which is slightly redundant but defensible for a nested field.

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, free calculator the description covers the essentials: inputs required, optional offer comparison, package mode, and the result shape in the absence of an output schema. The gap is the 21-parameter surface — an agent still cannot tell from the description how the optional booleans and enums (rights, exclusivity, season, geo) feed the formula, so it may omit levers that materially change the rate.

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

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

With 21 parameters and only 33% schema description coverage, the description carries substantial burden; it explains platform, medianViews (including the LinkedIn-impressions exception), niche, actualPaid, and the nested package/reuse semantics well. However, the many optional multipliers that presumably map to the formula — geo, season, concept, rightsTier, exclusivity, hasProps, hiredCrew, customSet, perpetual, onLocation, extras — are never tied back to BMV/CM/RM/QA/MA, leaving the agent to infer which levers matter.

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 output (fair sponsorship rate) and the exact method — 'Fair Rate = BMV × CM × RM × QA × MA' — plus the shape of the result (confidence band + breakdown). This makes it clearly distinguishable from the scoring/vetting siblings such as score_creator_fresh or vet_creator, which operate on creators rather than on a rate model over supplied inputs.

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 explicit minimal call recipe (platform + medianViews + niche), an optional comparison path (actualPaid to check an offer), and a dedicated mode for multi-platform campaigns via `package` with per-line reuse semantics. It does not explicitly say when to prefer this over a sibling like compare_creators, but the within-tool routing guidance is concrete and actionable.

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, so the safety profile is covered. The description adds genuinely useful context beyond them—that the call is free and should be used as a connectivity/setup check—but says nothing about rate limits or error behavior when the connection is invalid.

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

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

Three short sentences, front-loaded with the resource and returned fields, then the usage instruction and cost. No filler or repetition.

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

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

With no parameters and no output schema, the description carries the burden of describing results, and it does name the two returned values plus cost and recommended call order. Minor gap: it doesn't indicate the response shape or what happens on failure.

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; baseline 4 applies. 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?

Uses a specific verb and resource ('Check the account tied to this connection') and enumerates the returned data ('credit balance and per-creator pricing'), which separates it from scoring/vetting siblings. It does not explicitly name an alternative sibling, so it stops short of full differentiation.

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?

'Call first to confirm it works' gives clear ordering guidance for an agent starting a workflow. It provides context but no explicit exclusions or named alternatives among the many sibling tools.

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

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

With annotations already declaring readOnlyHint=true, destructiveHint=false and openWorldHint=false, the description adds real value by disclosing the return-state machine (pending payment, scanning, complete) and confirming the tool is free, which matters for repeated polling. It stops short of saying how often to poll, whether calls are cached or rate-limited, or how long a scan typically takes.

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

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

The core purpose and the polling precondition are front-loaded, and the return detail follows logically. The single long em-dash-laden sentence packs in a lot but is dense; the trailing 'Free, read-only' is a terse, useful closer 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?

There is no output schema, so the description must carry the burden of explaining return values, and it does so concretely: flags include the specific post, severity and description rather than counts, plus per-category lines across nine regulated sectors marking flagged/clean/not assessed. The main remaining gap is polling behavior (cadence, terminal states) for what is explicitly a poll-type tool.

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

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

Schema description coverage is 100% and the schema already documents check_id as 'The Check ID from start_background_check', so the description adds no new meaning about the parameter. One parameter at full coverage lands at the baseline of 3.

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

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

The description names a specific verb and endpoint ('Poll a Social Background Check started by start_background_check') and states the three return regimes (payment pending, scan progress, complete). It explicitly ties itself to the sibling start_background_check, so an agent can tell this apart from list_background_checks without opening either 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?

It clearly establishes the precondition that the check must have been started by start_background_check, which tells the agent when this tool applies. It does not state when to stop polling versus falling back to list_background_checks, nor any polling cadence, so there is no explicit exclusion or alternative routing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered elsewhere. The description adds genuinely non-structured behavior: three possible outcome states (in-progress, complete score, error) and the fact that failed jobs are auto-refunded, which matters for the agent's decision to retry or report failure. It omits any mention of job expiry or how long results remain retrievable.

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

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

Three short sentences: purpose, outcome states, polling cadence. The purpose is front-loaded and nothing is repeated wastefully; the refund note and cadence are the two highest-value facts and both are stated compactly.

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 so by enumerating progress, full score, and error. For a single-parameter polling tool this is close to sufficient; the only missing piece is terminal-state handling (whether to stop polling or how long a completed job's result stays available).

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 there is only one parameter, whose schema description already states it comes from score_creator_footprint or score_creator_fresh. The description restates that provenance but adds no new format, validation, or lookup guidance 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?

The description opens with a specific verb and resource: 'Poll a scoring job'. It also names the two sibling tools that create such jobs (score_creator_footprint, score_creator_fresh), so an agent can immediately separate this from job-creation tools or unrelated siblings like check_account or list_roster.

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 concrete when-to-use context (only for jobs previously started by the two score_* tools) and an operational rule of thumb ('Poll ~every 30s'), which is the exact guidance an agent needs to avoid hammering the endpoint. It does not say when to stop polling or what to do after a terminal state, so it stops short of full when/when-not coverage.

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?

Adds real behavior beyond the annotations: results are cached and never scrape live, and billing is spelled out (free for roster creators with a fresh score, 1 credit per already-scored creator off-roster, free when the creator shows as a gap). Nothing in the text explains why destructiveHint=true is set, and there is a mild tension between that annotation and the innocuous "cached" framing, but the description itself does not assert a contradicting safety claim.

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-loaded with the core action and output, then layered with the constraint, cost, and gap fallback — dense but each clause carries information. The single paragraph chains several distinct ideas together, so a little structural separation would improve scanability.

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 tool with no output schema, the description covers the input format, the returned shape (ranking, tier, risk count), cost model, caching behavior, and the missing-score case with a pointer to the fix. The only unaddressed edge is what happens with an unresolvable or ambiguous name.

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

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

Schema description coverage is 100%, so the schema already documents the single creators array, its 2–5 bounds, and the query field's name-or-handle format with the "Do NOT pass a platform" warning. The description's repetition of these constraints reinforces rather than adds meaning, and the credit-cost sentence describes billing, not parameter semantics.

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?

"Compare 2–5 creators side by side by their unified cross-platform CreatorScore... ranked best to worst with tier + risk count" states a specific verb, an exact input cardinality, the ranking basis, and the returned fields. It also distinguishes itself from the platform-level siblings by insisting on the whole footprint "never a single platform."

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 a concrete usage rule ("Pass each creator by NAME or @handle — NEVER ask the user for a platform") and routes the no-score case to score_creator_footprint with "no charge here," which is a useful alternative-plus-condition pair. It stops short of contrasting with vet_creator, find_creator, or get_creator_report, so sibling selection beyond the gap case is left 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 only say read-only, open-world, non-destructive; the description adds the material behavior they don't cover: the lookup is free with no scraping or web search, web search costs 1 credit and requires user consent, and scores always cover the whole footprint with nothing auto-attributed. That cost/consent and non-attribution context is the highest-value information here.

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

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

The core purpose and the free-vs-paid distinction are front-loaded, and every sentence carries usable content. There is mild redundancy — the credit cost and consent rule appear in both the description and the search_web schema field, and the caps-lock emphasis is heavy — 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?

There is no output schema, and the description compensates by naming the return payload (identity_group_id, linked platforms, score and recency). Combined with the cost model, the no-scraping guarantee, and the consent gate, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100% and both parameter descriptions already document the NAME/@handle format and the 1-credit, consent-gated behavior of search_web. The description restates the same meaning rather than adding format or edge-case detail, so the baseline of 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 ('Find a creator by NAME or @handle') plus the scope ('ranked FOOTPRINT candidates from our index'), and describes what each candidate contains. It is clearly distinguished from siblings like score_creator_footprint and compare_creators, which it frames as the follow-up step.

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

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

Gives an explicit workflow: lookup first (free, index-only), confirm the right person, then score/compare. It also names the fallback condition and gates it ('If the creator isn't in our index, set search_web:true... ONLY do it after the user says yes'), which is exactly the when/when-not guidance an agent needs.

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

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

The description carries non-obvious operational facts the annotations do not: the cost model (free for creators this account already paid to score, 1 credit as a cached read otherwise), that it never scrapes, and that the output includes a browser-openable PDF the user can share. The annotations only say readOnlyHint=false / destructiveHint=true without explaining the credit spend that plausibly accounts for the mutation flag; the description supplies that context rather than contradicting it.

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

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

Front-loaded with the core purpose, then a dense but purposeful content inventory, then cost/precondition/usage-routing. Long and heavy on ALL-CAPS emphasis, but nearly every clause conveys either report contents or a decision rule; only the repeated emphasis is expendable.

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 complex, multi-section report tool with no output schema, the description fully enumerates the return contents and the per-flag evidence fields, plus cost, preconditions, and sharing behavior. Nothing an agent needs to decide to call it or to set expectations for the user appears 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%, but the description adds a meaningful constraint the schema only hints at: 'Covers the WHOLE footprint from any one of the creator's handles,' clarifying that platform+handle need not be the account of interest. The section enumeration also makes the optional 'sections' filter's contents concrete beyond its bare enum.

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: retrieve the full CreatorScore report for a previously scored creator, and enumerates exactly what that report contains (risk flags with evidence, brand mentions with disclosure verdicts, SHAP drivers, demographics, score history, PDF). It is immediately distinguishable from score_creator_footprint, which is named as the producing step rather than the reporting step.

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

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

Gives explicit when-to-use triggers (user asks why a score is what it is, wants flags, brand deals/disclosure, or a shareable report) and an explicit fallback: 'If the creator has no score yet, use score_creator_footprint first.' It also states the precondition ('a creator you've already scored'), so the agent knows the prerequisite ordering between siblings.

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

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

Annotations already establish readOnly, non-destructive, closed-world behavior, so the bar is lower; the description still adds genuinely non-inferable facts: the link is public, requires no login for the recipient, and is free (relevant since buy_credits is a sibling). It does not say whether links expire or can be revoked, which is the one meaningful 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?

A single front-loaded sentence pair: the artifact first, then the audience, then the parameter source, then the cost note. Every clause carries information an agent would otherwise have to guess.

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-only tool with full schema coverage and no output schema, the definition covers purpose, input provenance, and cost. Only the link's lifecycle (expiry, revocability) is left implicit, which is a minor omission at this complexity.

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, and the description earns a step above by stating the provenance of identity_group_id ('from find_creator') and reinforcing that chaining in the schema-adjacent text. It adds no format detail beyond that, but for a single opaque ID none is needed.

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

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

The description names the concrete output — a public, no-login link to a creator's footprint profile — which is specific enough to distinguish it from get_creator_report or score_creator_footprint. The action verb is only implied ('a link to...'), but the resource and the artifact produced are unambiguous.

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

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

It gives the intended scenario ('for a colleague or a deck') and the prerequisite chain ('Pass the identity_group_id from find_creator'), so an agent knows both when to reach for it and what must precede it. It stops short of naming an alternative or an explicit when-not condition, so it is clear context rather than full routing guidance.

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

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

Annotations already declare readOnlyHint, destructiveHint=false, and closed-world, so the safety profile is covered and the description only needs to add context. It adds the trigger timing and hints that the output enumerates options plus their requirements, but says nothing about format, completeness, or whether calling it has side effects. Adequate but thin beyond the annotations.

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

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

Two short sentences with no filler, and the purpose is front-loaded ahead of the call trigger. Only 'what each option needs' is imprecise wording that slightly weakens an otherwise tight statement.

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?

A zero-parameter, read-only discovery tool with no output schema is a low-complexity case, and the description covers purpose and call timing. Given a 16-tool sibling set, it could do a bit more to frame itself as the entry point that routes to the scoring/vetting tools, which is the only 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline applies. Nothing in the description misdescribes the input contract.

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?

Specific verb+resource: it shows CreatorScore's capabilities and the requirements for each option. It is clearly distinct from the sibling tools, which are all concrete scoring/vetting operations rather than capability discovery. The phrase 'what each option needs' is slightly vague about whether it means prerequisites or parameters, keeping it from a 5.

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

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

Gives explicit triggers: on user connection and when the user asks what the agent can do. That is clear usage context with no exclusions, but it does not say when to avoid this tool or how to route from here to a specific sibling.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint false, closed-world), so the bar is lower. The description still adds useful non-annotation context: the operation is free, results are ordered newest first, and completed entries carry a browser-openable PDF link. It says nothing about pagination, default result count, or truncation behavior, which matters for a list tool.

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

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

Two tight sentences with the highest-value information (what is returned, cost, read-only) front-loaded and the sibling routing last. No filler; the only cost is that brevity here came at the expense of parameter coverage rather than through it.

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, and the description does adequately sketch the return shape (status, flagged categories for completed checks, PDF link), which is the main gap it needed to fill. However, for a filtered list tool with an undocumented status enum and limit cap of 200, the missing filter semantics leave an agent unable to use the tool's main selectivity features.

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%, so the description carries the full burden of explaining the two parameters and it does not. 'limit' is never mentioned, and 'status' appears only as an output field ('with status'), which can actively mislead an agent into thinking status is not a filter; the five enum values go unmentioned.

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

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

States a specific verb and resource ('List this account's Social Background Checks'), plus scope (this account), ordering (newest first), and payload (status, categories flagged, PDF link). It also names the sibling it is not, so an agent can separate it from check_background_check without opening either 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?

Explicitly routes the agent to check_background_check when full categorized findings for a single check are needed, which is the most likely confusion. It does not address other plausible siblings (start_background_check, buy_credits) or state prerequisites such as needing checks already created, so it stops short of full when/when-not 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 already cover readOnly/destructive/openWorld, and the description adds genuinely new operational facts: free, cached, never scrapes or charges, and the payload includes risk-flag titles rather than only a count. That is exactly the kind of cost and data-shape disclosure an agent needs before calling.

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

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

Front-loaded with the resource definition and return shape, then the trigger phrases. Slightly heavy on capitalized emphasis (FOOTPRINTS, TITLES) but the size is proportionate and no sentence is 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?

No output schema exists, and the description compensates by enumerating what each entry contains (unified score, tier, linked platforms, risk-flag titles). For a two-parameter read-only list tool, nothing material 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 100% and both parameters (limit, offset) are documented in-schema with defaults and bounds. The description adds nothing about pagination or page-size behavior, so the baseline of 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 (show/list) and a precisely scoped resource: creators already on the user's account, returned as unified cross-platform footprints with one entry per creator. The explicit 'never one row per platform' clause distinguishes it from per-platform listing siblings like find_creator or score_creator_footprint.

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 four concrete trigger phrases ('my roster', 'my creators', 'who am I monitoring', 'show my creators'), which is strong positive routing guidance. It does not name the alternative tool to use for creators NOT yet on the account (e.g. find_creator or score_creator_fresh), so the exclusion side is left 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 flag destructiveHint=true and readOnlyHint=false; the description explains why — the tool spends exactly 1 credit and mutates the index — and adds that previews are free, that scoring runs as a ~10-20 min background job returning a job_id for check_score_job, and that merging is never charged separately. These are non-obvious cost and latency behaviors an agent cannot infer from annotations.

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-loaded with the core purpose and credit cost, then ordered as discovery, two-step protocol, async behavior, and anti-pattern. The all-caps emphasis and some repetition ('NEVER offer to score just one platform', the repeated 'other handles' warning) add noise, but nearly every sentence carries an actionable rule.

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, yet the description tells the agent what each mode returns (preview: every account with profile URL, confidence, and discovery method; confirm: a job_id) and which sibling polls it. For a costly, asynchronous, state-changing tool this covers everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely extends the schema by explaining the confirm flag as a two-step preview/commit protocol and by clarifying that only accounts from the preview's offered list are incorporated. It adds workflow meaning rather than parameter syntax, which is the right contribution here.

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

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

States a specific verb and resource ('score a creator' producing a 'full cross-platform CreatorScore'), plus the scope constraint 'from a SINGLE handle, for EXACTLY 1 credit'. It explicitly separates itself from sibling tools, naming vet_creator, find_creator, and check_score_job, so an agent can route correctly without opening schemas.

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

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

Gives explicit when-to-use ('if a creator isn't in our index yet, that is EXACTLY when to call this'), an explicit when-not-to ('Do NOT run vet_creator with a hand-built handle list to build a footprint'), and the required workflow order ('Always preview first... unless the user explicitly says to skip verification'). Alternatives and their selection conditions are fully 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?

Beyond annotations, it discloses that the call scrapes and transcribes, runs the v2.2 model, is queued (poll check_score_job), and costs 1 credit — genuine operational context the annotations do not carry. Missing is any statement about what happens on a failed or partial scrape given destructiveHint=true, which is the one behavioral risk left implicit.

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, with the 'building block, not the product' framing front-loaded before the usage rules and mechanics. Heavy all-caps emphasis is functional but slightly noisy; every sentence still carries real information.

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

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

For a mutation tool that spends credits and enqueues async work, the description covers cost, the confirm gate, and the polling follow-up. It stops short of describing the shape of the returned score or how 'include' affects it, which matters somewhat because there is no output schema.

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

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

The description reinforces the confirm=true spend gate and ties it to a concrete cost (1 credit + live scraping), which adds meaning beyond the schema's 'Must be true to spend credits'. However, schema coverage is only 50% and the 'include' array — with five enum values and no description in the schema — is never explained, so the description leaves one parameter undocumented in both places.

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 ('Fresh-score ONE account') and immediately frames it as a building block rather than the product. It names the sibling score_creator_footprint as the real product, so an agent can distinguish the two without opening either 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 explicit when-to-use conditions (COMPLETE a footprint by filling a not-yet-scored account, or REFRESH one flagged STALE) and an explicit prohibition (NEVER offer single-platform scoring as an alternative). This is exactly the routing guidance an agent needs against a similarly named sibling.

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

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

Goes well past the annotations: discloses that this is a real one-time Stripe charge paid through a returned Checkout link, that the brand must open and pay the link, the exact tier prices, that VERIFIED sits in 'awaiting_consent' until the creator authorizes, and that it auto-refunds if consent never arrives. The destructiveHint=true annotation is made concrete by explaining money changes hands and a consent flow gates execution.

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 the critical 'SEPARATE from credits / one-time Stripe charge' warning in the first sentences. It is dense and uses all-caps emphasis plus repeated price figures that also appear in the schema, which is slightly redundant, but nearly every sentence carries operational information.

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

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

For a mutating, payment-triggering tool with no output schema, it covers pricing, payment mechanics, tier gating, consent state, refund behavior, and the polling follow-up. The main residual gap is that it never says which identifier (check id) the response returns for use with check_background_check, leaving the actual return shape implicit.

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 defines every parameter; the description nonetheless adds the consequence chain for creator_email (consent email, awaiting_consent state, auto-refund) and the pricing distinction for tier, which the schema only states flatly. It adds real meaning for the two decision-driving parameters, though handle/platforms get no extra treatment 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 concrete verb+resource ('Order a Social Background Check on a creator') and immediately scopes it as a one-shot full-history brand-safety scan with an enumerated list of categories. It explicitly separates this from CreatorScore and API credits, and names check_background_check as the polling counterpart, so an agent can distinguish it from score_creator_footprint or vet_creator.

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 clear when-to-use context: brand-safety scan distinct from trust scoring and credit purchases, plus the decision rule between tiers (QUICK auto-starts; VERIFIED requires creator_email and creator consent). It does not explicitly compare against sibling tools like vet_creator or score_creator_footprint, so the routing guidance is strong but not exhaustive.

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?

Goes well beyond the annotations by disclosing caching, no scraping, automatic footprint linking, staleness behavior, empty-result semantics, and the credit model (free on a fresh roster score, 1 credit otherwise). The one gap is that destructiveHint=true is never explained — nothing in the text says what is destructive or irreversible, though the auto-linking and credit charge hint at side effects.

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

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

Front-loaded with the core purpose and skillfully uses emphasis and a clear example to convey the fallback path. Slightly redundant: the caching point is made twice ("Cached, never scrapes" and "This tool is a cached reader") and the credit sentence is dense enough to bear rereading.

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 still names every returned field, and it covers the cost model, staleness, and the failure path an agent will actually hit. Nothing an agent needs in order to call it or recover from an empty 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 100% and the single parameter is already described in the schema as the same creator's accounts consolidated into one footprint, so the description mostly restates that. It adds mild value by stressing the accounts must belong to the SAME creator, but contributes no format, limit, or enumeration guidance 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 verb and resource ("Read the CACHED unified score for a creator") and enumerates exactly what comes back: the unified CreatorScore, per-platform breakdown, last-scored date/staleness, and worst risks. It explicitly separates itself from score_creator_footprint, so an agent can route correctly without opening either 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 a positive precondition (you already know the accounts or the creator is on your roster) and an explicit negative branch with a named alternative: on an empty result, do NOT ask the user for other handles, switch to score_creator_footprint. It also closes the tempting wrong path by stating outright that this is not how to build a new footprint.

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