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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-derivable context — the env-var auth requirement for API mode, that manual mode performs no network calls, and that the price range comes with 'the exact formula and assumptions'. However it doesn't disclose error behavior (invalid handle, insufficient posts) or the response shape beyond a field list.

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 front-loads the deliverable and then the modes, saving, and return-value note. Every clause carries information, though the mid-sentence accumulation of output fields and the formula/assumptions aside make it slightly heavy to scan.

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

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

With no output schema, the description does the important work of naming what is returned (profile fields, engagement metrics, price range with formula, plus a `narrative_prompt` the agent is expected to use) and clarifies that nothing is persisted. Given zero required parameters and nested objects, the main missing piece is the mutual exclusivity of username vs manual.

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 67%, so username and the manual sub-object are already documented in the schema; the description only restates that manual takes 'profile+posts'. `max_posts` is undocumented in both schema and description, and the fact that the top-level inputs are effectively either/or (username XOR manual) is implied but never stated as a constraint. Baseline 3 is appropriate given the schema does most of the work.

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 ('Builds a structured sponsor profile for an X creator') and enumerates exactly what the profile contains (niches, audience, content style, engagement metrics, price-per-post range). It also names the sibling it is not — 'Saves nothing (use save_creator_profile)' — so an agent can distinguish it without opening another 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 presents the two operating modes: X API source (requires X_BEARER_TOKEN) or `manual` profile+posts with 'No network'. It also routes the persist step to save_creator_profile. It stops short of stating when to prefer manual over the API (e.g. rate limits, handle not found), so it is clear context without full exclusions.

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 (destructiveHint=true, idempotentHint=false) by disclosing that the action is irreversible and, crucially, that the first call writes nothing and only returns a preview plus confirm_token. The instruction to show the preview and re-call with identical arguments is exactly the behavioral detail an agent needs for a destructive operation.

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: purpose, irreversibility, then the two-step protocol front-loaded with the critical constraint. 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 destructive mutation with no output schema, the description covers the essentials: state constraints, irreversibility, and the full preview/confirm lifecycle including what the first call returns. An agent can invoke it correctly without further inference.

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 only 33%, with `deal_id` and `reason` undocumented in both schema and description. The description does explain the confirm_token two-step semantics, but that meaning is largely already present in the schema's confirm_token description, so it adds only marginal value and leaves the other two params 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?

States a specific verb (cancels) plus resource (deal) and narrows the applicable state to `offered` or `accepted` deals. This clearly distinguishes it from siblings like respond_to_offer or delete_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 a clear condition for use (only offered/accepted deals) and an explicit invocation protocol for the two-step flow. It does not name an alternative tool, but no obvious sibling performs the same job, so context is otherwise sufficient.

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 declare the generic write profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds behavior annotations cannot express: the two-step preview/confirm protocol, the guarantee that nothing is written on the first call, the user-approval requirement, and the initial status value. This is exactly the kind of non-obvious side-effect disclosure the description should 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?

Front-loads what the tool does and the resulting state, then spends its remaining sentences on the one thing an agent will get wrong: the two-call confirm flow. No filler, no restatement of the title.

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 write tool with 11 parameters and no output schema, the description covers the critical behavioral protocol, the payload fields and the resulting status. It does not describe what the preview actually returns or note that the creator must already be saved and valid, leaving a small gap for a mutation of 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 description coverage is only 27% across 11 parameters, so the description must compensate. It does add meaning for confirm_token, disclosure, must_include_phrases, must_include_link, amount and product, but leaves brand, currency, notes and post_by entirely undocumented in both the schema and the prose, and gives no formats (e.g., date pattern, currency code, handle syntax).

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 ('Brand creates an offer to a saved creator') and enumerates the payload it carries: amount, product, post requirements, disclosure markers. It also pins the resulting state (`offered`). It does not explicitly contrast itself with the creator-side sibling `respond_to_offer`, so sibling differentiation is only implied.

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 concrete operating instructions: the first call without confirm_token returns only a preview, the preview must be shown to the user, and the second call must reuse identical arguments plus the token. It does not say when this tool is preferable to sibling alternatives (e.g., respond_to_offer or cancel_deal), 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 declare readOnlyHint, idempotentHint, closed-world, and non-destructive behavior, so the safety profile is covered structurally. The description adds genuinely new context beyond the annotations: it discloses the conditional logic behind the returned value (x_api when X_BEARER_TOKEN is set) and a security guarantee — 'Never reveals the token' — that no annotation conveys.

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, front-loaded with what is returned, followed by the conditional value mapping and the security caveat. Every clause earns its place and 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 must carry the return contract, and it does outline the three returned facts and the possible data-source values. It stops short of describing the shape or format of the response (e.g., ordering, how the path/pricing fields are presented), which is a minor remaining gap for a no-argument diagnostic 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?

The tool takes zero parameters, so per the rubric the baseline is 4 and there is nothing for the description to disambiguate. No misuse risk exists from 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?

The description states a specific resource — the active X data source, data file path, and pricing assumptions — and enumerates the possible data-source values (x_api, fixture, none), so an agent knows exactly what introspection this returns. It is clearly distinct from the sibling tools, which all deal with creators, deals, and payouts rather than system configuration.

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 rather than stated: an agent can infer it should call this to discover which backing store is active before fetching data, but there is no explicit when-to-use or when-not-to-use guidance, nor any named alternative for introspecting configuration.

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, but the description adds substantial context beyond them: the permanence of removal, the precondition that blocks deletion, and the fact that the first call writes nothing. It also discloses that the first call returns a preview object plus a confirm_token, which is core non-obvious behavior.

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 sentences, front-loaded with the action and its blocker, then the two-step protocol. Every sentence carries information needed to call the tool correctly; 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?

No output schema exists, yet the description explains what the first call returns (a preview and a confirm_token) and what the second call does, so an agent knows the full interaction lifecycle. Nothing material is missing for a destructive two-step 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 coverage is 100%, so the baseline is 3, and the schema already documents confirm_token. The description still earns above baseline by clarifying the token contract (obtain from preview, pass with identical arguments) and implying the two-call protocol the parameter participates in.

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 (permanently removes) and resource (a saved creator), and the scope word 'permanently' distinguishes it from softer mutations. An agent can immediately tell this apart from read-oriented siblings like get_creator or list_creators.

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 preconditions for refusal (open deals that are offered, accepted, or verified-but-unpaid) and prescribes the exact invocation sequence: preview first, user approval, then re-call with identical arguments plus confirm_token. Nothing about when/when-not 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 already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds the content scope (profile + analysis + deals), but says nothing about behavior on a missing username, pagination of the embedded deals, or freshness of the analysis.

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 that names the resource and its contents with zero filler. Nothing is redundant or padded.

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 burden of describing return content, and it does list profile, analysis, and deals. That is adequate but thin: it does not indicate the shape, depth, or volume of the embedded deals list, nor error behavior for invalid handles.

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 'username' parameter is well documented in the schema (X handle, with or without @). The description adds no parameter-level detail beyond that, so the baseline of 3 is appropriate.

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 a specific verb+resource ('Get saved creator') and enumerates the payload ('profile and analysis, plus their deals'), which separates it from list_creators. However it does not clearly differentiate itself from the sibling analyze_creator, whose name also implies producing analysis, so the agent cannot fully disambiguate on purpose alone.

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 such as list_creators or analyze_creator or get_deal. The agent must infer the retrieval context purely from the tool name.

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 and destructiveHint=false, so the safety profile is covered. The description adds that the response aggregates requirement, status history, verification checks and payout record, which is useful context about the shape of the read. It says nothing about authorization needs, missing-deal behavior, or payload size.

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 that lists the returned components with no filler. It is a noun fragment rather than a sentence, but no words are wasted and the most important content leads.

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 the return value, and it does list the four payload sections. However, it omits identifier usage, error behavior when a deal is not found, and any relationship to sibling write tools.

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% and the description never mentions deal_id or its required 'deal_xxxxxxxxxx' format. With one parameter and no schema-level documentation, the description is the only place this could be clarified and it does not, so it fails to compensate for the coverage gap.

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

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

The description names the resource (a full deal) and enumerates what the payload contains: requirement, status history, verification checks and payout record. That is a specific verb+resource statement an agent can act on. It does not, however, distinguish itself from the sibling list_deals, so it stops short of a 5.

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

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

There is no guidance on when to call this versus list_deals, or versus the sibling tools verify_deal_post, record_payout and cancel_deal. The agent must infer that 'Full deal' means the single-deal counterpart to list_deals, and no prerequisites or exclusions are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and closed-world behavior, so the safety profile is covered. The description adds the returned-field set (niches, followers, engagement rate, price range) and confirms filtering is optional, but says nothing about pagination, ordering, or result limits for a list operation.

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 resource returned, with zero redundant filler. Slightly terse, but nothing wastes space.

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 one-parameter read-only tool with no output schema is a low-complexity case, and the description covers the essentials. However, it omits any indication of result volume, pagination, or default ordering, which an agent listing saved creators would plausibly 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 coverage is 0%, so the description must compensate. Saying 'optional niche filter' usefully conveys that the niche parameter is optional and narrows results, but it adds no syntax or behavioral detail beyond the schema's enum, which is self-explanatory.

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 identifies the resource (saved creator profiles) and its attributes, but offers no verb and no differentiation from siblings like get_creator, match_creators, or analyze_creator, which all operate on creators. An agent can guess it lists, but nothing in the text distinguishes it from other creator-reading tools.

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?

'Optional niche filter' is the only usage hint and only describes one parameter, not when to reach for this tool versus get_creator or match_creators. There are no exclusions, prerequisites, or selection criteria for alternatives.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the filtering behavior over an unfiltered list, but says nothing about ordering, pagination, or result limits for a read-only collection endpoint.

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

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

One short sentence with no padding, and the resource is front-loaded. It loses a point only because the fragment "Deals with status" is grammatically ambiguous and reads as a fragment rather than a self-contained 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?

No output schema exists here, so the description should carry more of the return-shape burden; it does not say what an unfiltered call returns, how results are ordered, or whether they are paginated. Annotations plus the schema cover safety and the two params, leaving the definition minimally viable 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?

Both params are optional filters and the description confirms that, which adds some meaning. But schema coverage is 50% (status has an enum with no description), and the description does not explain the enum values, the @-handle handling, or what is returned when no filter is supplied – so it only partially compensates.

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

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

The description names the resource (deals) and the two filter axes, but the verb is only carried by the name/title ("list_deals" / "List deals") – the fragment "Deals with status" never states that it returns a collection. It also gives no differentiation from the sibling get_deal, so an agent must infer the list-vs-get distinction.

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 use this versus get_deal, list_payouts, or other siblings, and no exclusions or prerequisites. The only usage signal is the implicit "filterable by status or creator."

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, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds one meaningful behavioral fact beyond the annotations: 'This server never moves money,' which reassures the agent in a context full of money-moving siblings. It adds nothing about result ordering, pagination, or refresh behavior.

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 zero padding, and the resource is front-loaded. The second sentence is a capability disclaimer rather than a continuation of the tool's own behavior, which makes it slightly less tight than an ideal single-purpose sentence, 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 parameters, no nested objects, and annotations carrying the safety profile, the description covers what the agent needs to invoke it. The lack of an output schema means the return shape (provider list plus availability flag) is only implied, but for a no-arg read tool this is close to sufficient.

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 to document and the baseline is 4. The description correctly avoids inventing parameter talk.

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 (payout providers) and the attribute returned (availability), so the agent knows this is a discovery/enumeration tool. It is a noun phrase rather than an explicit verb+resource statement, and it does not contrast itself with siblings like list_payouts or record_payout, but the resource is 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?

There is no statement of when to call this versus alternatives, nor any prerequisites. The agent must infer that this is the discovery step preceding record_payout/list_payouts. 'whether they are available' hints at the filtering purpose but does not constitute usage 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=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds only a return-content hint ('totals per currency') and says nothing about scope, ordering, or pagination.

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 short sentence with no filler, front-loading the resource before the return detail. It is terse rather than padded, though it errs toward under-specification.

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 is the only source for what comes back, yet it only mentions per-currency totals and omits record shape, ordering, and whether the list is scoped or complete. Annotations carry the safety profile, so the remaining gap is modest but real.

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; the baseline for a parameterless tool 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 the resource (payouts) and hints at the return content ('totals per currency'), but has no explicit verb and no scope qualifier such as date range or account. It does not distinguish itself from the sibling record_payout or from list_deals/list_creators beyond the noun.

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 mention of prerequisites, and no reference to any sibling tool as an alternative. The agent must infer that this is the read counterpart to record_payout.

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 and destructiveHint=false, so the safety profile is covered. The description still adds real value beyond them: it states the operation is deterministic and explainable, and that it 'saves nothing', which confirms the non-persistent behavior. It does not mention prerequisites or limits on how many saved creators are considered.

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 zero filler, front-loaded with the core ranking action and followed by the scoring components, the explainability guarantee, and the no-side-effects note. Every sentence 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 usefully sketches the return shape (per-component scores, reasons, suggested offer), which is the strongest part of the definition. However, for a 7-parameter tool with a nested budget object, it leaves most input semantics and the ordering/limit behavior unexplained, so an agent knows the intent but not the full calling contract.

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 43% across 7 parameters, so the description carries a compensation burden it does not meet. It never mentions limit, languages, min_followers, description, or the target_niches override; 'product brief' and 'budget fit' only loosely gesture at product and budget_per_post without adding format or constraint meaning.

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 (ranks), a specific resource (saved creators) and the ranking method (niche fit, audience fit, budget fit) against a product brief. This is clearly distinguishable from list_creators (enumeration), get_creator/analyze_creator (single-creator views) and create_offer (mutation).

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 only implied: the phrase 'saved creators' hints that the creator library must already be populated and that a brief is the input, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling tools. An agent can infer the context but is given no 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 only give generic hints (readOnlyHint=false, destructiveHint=false, idempotentHint=false), while the description supplies the real behavioral payload: no money moves on the default path, x_money is a stub that always refuses, the deal is marked paid, and the first call writes nothing. This is exactly the context 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?

Three dense sentences, each carrying distinct load: what the tool does and its provider modes, the side effect on the deal, and the two-step protocol. The two-step rule is front-loaded as a labeled block so it is not missed.

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 with no output schema and no annotations covering the workflow, the description covers the critical path well (side effects, preview semantics, confirmation). It stops short of stating permission/authorization requirements or what happens on duplicate payouts for the same deal, which would matter for a financial write.

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 50%, and the description fills the biggest gap by explaining the provider parameter's two modes and the confirm_token contract (omit first, pass with identical args second). It also ties 'reference' to the payout flow, though 'amount' and 'note' semantics beyond the schema are not addressed.

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 resource ('Records that a verified deal was paid, via a payout provider') and immediately scopes it against siblings by detailing provider behavior, so an agent can distinguish it from list_payouts/list_payout_providers 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?

It states exactly when each provider applies ('manual' is a ledger entry only and does NOT move money; 'x_money' always refuses), and gives explicit operating instructions for the two-step preview/approval flow including 'only after they approve call again with the same arguments plus confirm_token.'

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 declare the mutation/safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false); the description adds the crucial behavior that the first call writes nothing and only returns a preview plus a confirm_token. This non-obvious, two-phase write semantics is exactly the kind of context annotations cannot express, and it does not contradict them.

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 tightly packed sentences with no filler; the state transitions come first and the mandatory two-step protocol is front-loaded as 'TWO-STEP'. Every clause carries actionable 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?

Given no output schema, the description usefully explains what the first call returns (a preview and a confirm_token). It leaves minor gaps—what happens if the deal is not in `offered` state, and no mention of the optional `note` field—but covers everything needed to invoke the tool 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?

With only 25% schema description coverage, the description must compensate, and it does for the critical parameter: it explains that confirm_token is omitted on the first call and must be supplied with identical arguments on the second. The `note` parameter and the deal_id format remain undocumented in both places, which keeps this below a 5.

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 ('records the creator's decision') on a specific resource ('an `offered` deal') and spells out both outcome transitions (accept -> `accepted`, decline -> `declined`). An agent can distinguish this from siblings like cancel_deal or create_offer because the precondition state (`offered`) and the resulting states are named.

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 guidance for the two-step flow: call without confirm_token for a preview, show it to the user, and only re-call after their approval. It does not, however, name alternative tools (e.g. cancel_deal) or state when this tool should not be used, so it stops short of 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?

Adds substantial value beyond the annotations: it discloses that the write overwrites prior analysis, that metrics are re-fetched on confirm, and critically that the first call writes nothing and only returns a preview + token. This makes the destructiveHint/idempotentHint profile actionable rather than abstract.

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 what it does, then the overwrite consequence, then the two-step mechanics. Four dense sentences with no filler; the preview/confirm warning is placed where the agent needs 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?

Even without an output schema, the description describes what the first call returns (a preview and confirm_token), which is the key behavioral contract for a two-step mutation. Nothing essential to correct 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?

With 80% schema coverage the schema already documents most params, but the description adds real meaning for confirm_token (omit to preview, pass identical args to apply) and the manual-vs-X selection. max_posts and payout_handle remain unexplained in text, keeping it from a 5.

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 specific verbs (analyses, saves/refreshes) and the exact resource (creator profile in the marketplace), and distinguishes the X API path from the `manual` path. An agent can differentiate it from siblings like analyze_creator or get_creator purely from the text.

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 via the explicit TWO-STEP flow and the 'show preview, then confirm' instruction, plus the X-vs-manual branch. It stops short of naming alternatives (e.g., analyze_creator for analysis-only), so it is clear context without explicit exclusions.

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 mutation (readOnlyHint=false) but the description carries the real behavioral load: the first call writes nothing, only a preview and confirm_token are returned, confirmation requires all checks to pass, and it marks the deal `verified`. It also discloses the token-absent fallback is recorded as manual attestation.

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

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

Purpose, fallback, and the two-step flow are front-loaded and ordered logically; the final 'TWO-STEP' block is clearly delineated. It is dense with several distinct concepts, but each sentence (token fallback, preview semantics, confirm requirement) 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?

Despite no output schema, the description explains the returned preview/confirm_token and the condition under which the write applies, which is exactly what an agent needs to drive a two-call workflow. The manual-attestation path is also 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?

Schema coverage is 75% and the description still adds meaning: `post` accepts a URL or id, `confirm_token` must be omitted on the first call and reused with identical arguments, and `manual_attestation` is conditioned on X API unavailability. Minor gap: it does not restate the `deal_id` format, but that is covered in 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 ('Fetches the creator's post ... from X and checks author, required phrases/link, disclosure, and that it was posted after acceptance') and names the concrete outcome ('marks the deal `verified`'). No sibling tool performs post verification, so the agent can select it unambiguously.

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 and alternatives: use `manual_attestation` when there is no X token, and use the two-step confirm flow otherwise. It also specifies the sequencing requirement (first call → show preview → approval → second call with confirm_token), leaving nothing to inference.

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