Creator River

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

Goes well beyond the annotations: it discloses the credit cost (0.5 the first time per creator, free thereafter), the unlocking side effect, and the exclusion constraint that blocks the call. The idempotentHint is effectively explained by the repeat-add-is-free note, and no behavior contradicts readOnlyHint=false or destructiveHint=false.

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 scope, and every clause carries information (cost, alternative, precondition). The parenthetical about reveal_contact and the mid-sentence clause about unlocking make it slightly dense, but no sentence is wasted.

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

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

Covers the mutation's cost, idempotent re-add behavior, side effect on the originating search, and the blocking condition, which is what an agent needs without an output schema. What the call returns is unspecified, but since no output schema exists this is a minor gap for a success/failure-style add operation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond it: it explains that searchId marks the creator as added in that originating search, which is a side effect not obvious from 'The search the creator came from'. campaignId and creatorId gain no extra detail, keeping it below 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 and resource ('Adds a creator to a campaign') plus the stage ('at the outreach stage'), and explicitly contrasts with the sibling reveal_contact, which also adds a creator. An agent can distinguish it from reveal_contact and save_creator without opening the schema.

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

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

Gives an explicit when-to-use rule ('build a shortlist before deciding whom to contact'), names the alternative (reveal_contact) and notes what it shares, and states a hard precondition: a creator excluded from the campaign cannot be added. Nothing about selection 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?

Goes well beyond the readOnly/openWorld annotations by disclosing cost behavior ('free, does not count against the daily search limit'), persistence behavior ('not kept as a search'), and result shape ('names but no handles'). The quota and persistence details are exactly the kind of context 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 action and ordering, then routing, then cost, then output caveat — a sensible priority order. The phrase 'with no description to match, as the dashboard's Discover list does before a search' is slightly convoluted but 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 13-parameter, filter-only read tool with no output schema, the description covers ordering, cost, persistence, and the key output limitation (names but no handles). Only minor gaps remain, such as default result count, which the schema already supplies.

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 each of the 13 filters is already documented in the schema, so the description adds little parameter-level meaning. It only implicitly signals the absence of a free-text/keyword parameter via 'no description to match'; the niche/market semantics are already 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 (lists) and resource (creators) plus ordering (most followed first) and an explicit negative scope ('with no description to match'). It clearly distinguishes itself from search_creators by framing this as the pre-search Discover list.

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 when-to-use example ('the biggest beauty creators in the US') and an explicit when-to-use-the-alternative rule ('use search_creators when the user describes what the content should be about'). The routing decision is fully specified.

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 idempotency ('confirming the same terms again changes nothing'), cost ('free'), and absence of external side effects ('it sends nothing to the creator'), which reinforces openWorldHint=false. The stated prerequisite and resulting pipeline stage are exactly the context an agent needs before mutating state.

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

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

Four short sentences, front-loaded with the action and state transition, then conditions and caveats. The one-word 'Free.' earns its place as a cost signal, though the paragraph is slightly dense and could be split more cleanly into when-to-use versus behavior.

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, the description covers the important ground: the stage the record moves into, the no-side-effect guarantee, the idempotency behavior, and the prerequisite email. Only a fuller sense of what the caller should verify afterward is missing, which is a minor gap.

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

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

Schema description coverage is 100%, so every parameter including terms, price, deliverables, and liveWindow is already documented in the schema. The description adds only a general reference to 'the agreed terms' and no format or usage nuance beyond that, so the baseline 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 ('records that the creator agreed to work with the user') plus the resulting state change ('moves them to the collaboration stage, waiting on the user to prepare it'). This is clearly distinguishable from siblings like record_reply and send_email, since the description explicitly says it 'sends nothing to the 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 gating condition ('call it only once the creator has clearly said yes to the terms') and a prerequisite ('needs an email sent first'). It stops short of naming a sibling tool for the alternative case (e.g., when the creator has not yet agreed), so it falls just short of the top mark.

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=false, destructiveHint=false and openWorldHint=false, so the mutation profile is covered. The description adds decision-relevant context beyond that — the operation is free and it produces a grouping object whose id is reused downstream — but says nothing about duplicate handling, permissions or whether edits are reversible.

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 action, then cost, then the follow-on workflow. Nothing is redundant with the title or schema, and the fragment 'Free.' earns its place as a one-word decision fact.

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 three-parameter mutation with no output schema, the description covers purpose, inputs, cost and the consumer of the result (the campaign id for search_creators). The main gap is failure/duplicate behavior, which an agent would want to know before calling a create 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%, so parameters (name defaulting to the brief's first line, brief, status default draft) are already fully documented in the schema. The description adds only framing about what a brief contains and what the returned campaign id is for, which is at the baseline level.

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 gives a specific verb and resource ('Creates a campaign from a brief') and decomposes the overloaded 'brief' parameter into product, goal and creators. It also positions the tool relative to search_creators, though it never contrasts with the sibling list_campaigns or get_campaign_status.

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?

'Free' plus 'Campaigns group the creators you contact; pass the campaign id to search_creators to rank results for the brief' tells the agent exactly when this tool is the right first step in a workflow. No explicit exclusions or when-not guidance are given, which keeps it short of 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?

Goes well beyond the annotations: discloses the resulting state ('move to closed'), irreversibility across two named sibling tools, that conversations remain readable, an optional side effect when searchId is passed, and that credits are not refunded despite being free. This is exactly the mutation context an agent needs before acting.

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: outcome first, then the optional-parameter side effect, then cost and usage trigger. No filler, and the irreversible consequence is front-loaded.

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?

Complete enough to call safely: outcome state, irreversibility, cost, and the optional parameter's effect are all covered. Only minor gaps remain, such as what the return payload looks like, which matters little for a no-output-schema 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 baseline is 3; the description earns above that by explaining the optional searchId effect (dropping the creator from that search's results, tied to get_search) rather than leaving it as 'a search to drop the creator from as well'.

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

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

Names a specific verb+resource ('Takes a creator out of a campaign') and immediately scopes it with 'for good' and the closed-state outcome, which distinguishes it from sibling removal tools like unsave_creator or remove-style operations on saved lists.

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 trigger ('Use it when the user rules a creator out') and clarifies what it is not by noting add_creator and reveal_contact cannot undo it. It does not name a direct alternative for softer removal, but the when-to-use guidance is clear.

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 readOnlyHint and openWorldHint, so the description carries the interesting behavior itself: data is redacted per row (handles and profile links only for unlocked creators, emails only for already-revealed ones), rows are rank-ordered, and the call costs nothing. The notable omission is any sense of output size, row caps, or truncation behavior for a potentially large CSV.

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 dense, front-loaded sentences with no filler; the output format and redaction rules come first. The final clause ('Save csv to a file named filename') is terse to the point of being ambiguous about where the filename comes from.

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

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

With no output schema, the description correctly steps in to describe the return value as CSV text with one row per creator and which columns are populated. For a two-parameter read tool it is nearly complete, missing only volume/truncation expectations and empty-result behavior.

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%, including an enum and a description for searchId, so the schema already defines both parameters. The description adds no meaning to searchId or to the 'all' vs 'added' scope choice, and its trailing 'filename' reference points at something that is not actually a parameter, which could momentarily confuse an agent about what to pass.

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 ('Returns a search's results as CSV text') plus the shape of the output ('one row per creator in rank order'), which distinguishes it from get_search and search_creators in the sibling list. An agent can tell this is the export path, not the browsing path, without opening a 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 clear context for use: it is the dashboard-equivalent export, it is 'Free' (contrasting with credit-consuming siblings like reveal_contact/unlock_creator), and it ends with a directive to save the CSV to a file. It stops short of naming an explicit alternative or a when-not condition (e.g., use search_creators for paging/inspection instead of a bulk dump).

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 and openWorldHint=false, so the description goes beyond them by disclosing cost ('Free'), exact-match matching semantics, cross-platform search scope, and the meaning of an empty result. It does not mention rate limits or result ordering, but nothing essential for correct invocation is missing.

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 action and input form, then scope, then outcome semantics. Every clause carries distinct information: cost, matching rule, and empty-result meaning.

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

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

There is no output schema, so the description correctly explains what comes back (a creatorId) and how to interpret the failure case (empty list means not in Creator River). For a single-parameter read-only lookup this is everything an agent needs.

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

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

Schema coverage is 100% and already documents the reference format with an example, so the baseline is 3. The description adds real meaning beyond the schema: matching is by exact handle, and the same handle is checked across every platform, which is not inferable from the parameter definition alone.

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 ('looks up a creator'), the input form (@handle or profile link), and the scope ('on every platform where that exact handle is in Creator River'). This distinguishes it clearly from discovery-oriented siblings like search_creators, browse_creators, and find_similar_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 a concrete trigger: use when 'the user names' a creator by handle or link, and names the follow-on tools (get_creator, add_creator, reveal_contact) that consume the returned creatorId. It does not explicitly state the inverse case (use search_creators when the user describes rather than names a creator), which keeps it from 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?

Goes well beyond the readOnlyHint/openWorldHint annotations: discloses quota cost ('each call counts against the daily search limit'), that no unlock is required, that names are returned without handles, the 0-1 matchScore range, and that the search is persisted and re-readable via list_searches/get_search. That is exactly the operational context an agent needs before spending a limited call.

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 definition and packs cost, filtering, and output format into one dense but readable block with no filler. It is close to overloaded in a single sentence-chain, which slightly hurts scanability, but every clause carries 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 9-parameter read tool with no output schema, the description covers what an agent must know: input sourcing, quota implications, campaign-based exclusion, the shape of results (names, matchScore), and downstream persistence. 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?

Schema description coverage is 100%, so all nine parameters are already documented, and the description largely restates creatorId sourcing and campaignId exclusion rather than adding new semantics. It contributes only a small amount of extra framing (no handle/unlock needed) beyond the schema baseline.

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 ('Finds creators whose content is closest to one creator's, on the same platform') and scopes it to a similarity lookup keyed on creatorId. This is clearly distinguishable from search_creators, which is a keyword/discovery search rather than a nearest-neighbor lookup.

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?

Explains the entry condition clearly: 'pass the creatorId of a search result, no handle or unlock needed' and notes the campaignId exclusion path. It implies but never explicitly states when to prefer this over search_creators or get_creator, so there is a small gap in 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 openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: the call is free (no credit consumption) and doubles as an API-key validity check, which an agent cannot derive from annotations. It stops short of covering failure behavior or rate limits, so not a 5.

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

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

Two sentences, zero filler. The return contents come first, the actionable routing guidance ('call it first', 'before spending credits') second — correctly front-loaded.

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

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

With no input parameters and no output schema, the description carries the return-value burden itself and does so by enumerating the four returned data categories. Nothing an agent needs in order to decide to call this and interpret the result 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The description correctly avoids inventing parameter discussion and instead spends its words on what is returned.

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 ('Returns') plus an enumerated resource set: credit balance, per-action prices, plan, and today's usage against daily limits. This is unmistakably a billing/account-status tool, easily separated from the campaign and creator tools in the sibling list.

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 with no inference required: 'Call it first to confirm the API key works, and before spending credits.' It also states the cost precondition ('Free'), which is the deciding factor for calling it ahead of paid 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 that this is a safe read (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description still adds real behavioral context the annotations do not: the call is free, counts always span the whole campaign even when one stage is listed, and items are ordered most-recently-active first. It stops short of describing response formatting details.

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 description is front-loaded with what the tool returns before moving to cost, ordering, and pagination instructions, and almost every clause carries information. The closing sentence about deciding what to do next is slightly generic padding but also serves as usage framing.

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 explain return values, and it does describe the payload shape (searches, creators per stage, next action, waiting-on party) plus count semantics. It leaves the exact field names and per-item structure implicit, which is a modest gap for a tool with four parameters and 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?

Schema coverage is 100%, so every parameter is already documented in the schema, and the baseline is 3. The description does add one genuinely useful interaction rule beyond the schema — that paging requires stage and that limit applies per stage while counts remain campaign-wide — but it repeats the schema's own 'needs stage' pairing rather than extending it.

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 uses a specific verb and resource ('Shows where a campaign stands') and enumerates exactly what comes back: searches run plus creators grouped by stage, each with next action and who the conversation is waiting on. That detail distinguishes it from siblings like list_campaigns (which just enumerates campaigns) and get_conversation (single thread), so an agent can pick it without opening the schema.

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

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

It gives a clear decision context ('Use it to decide what to do next across a campaign') and explicit operational guidance for the pagination case: pass stage, then read page 1, 2, … until you have count items. It does not name sibling alternatives or state when not to use it, which keeps it from 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 and closed-world, so safety is covered; the description still adds real value with 'Free' (cost profile), deterministic ordering ('oldest first'), and the null-thread empty state. It does not cover pagination or size limits for large threads, which keeps it from a 5.

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 compact sentences, front-loaded with the return payload, then the usage trigger, then the edge case. Every sentence carries distinct information with no restatement of the name or annotations.

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 shape, and it does: the fields returned, the message/event inclusion, and the ordering. For a two-parameter read tool with full annotation and schema coverage, nothing an agent needs to invoke or interpret it is missing.

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

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

Schema description coverage is 100% and both parameters (creatorId, campaignId) document their own provenance, so the schema does the work. The description only implies the pairing of campaign plus creator and adds no format or sourcing detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Returns the email thread with a creator in a campaign') and then enumerates the contents: stage, waiting-on, next action, agreed facts, messages and events. An agent can distinguish this read tool from siblings like send_email or get_creator 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?

Explicitly routes usage: 'Check it for replies after send_email,' which ties this tool to a concrete workflow moment. It also warns that the thread is null until the first email is sent, avoiding a false-empty reading. No explicit when-not or alternative tool is named, so not 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 establish that this is a read-only, closed-world operation. The description adds meaningful behavioral context beyond annotations: the call is free, certain fields are hidden until the creator is unlocked, and campaignId extends the response with campaign progress.

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 description is front-loaded with what the tool returns, followed by the free/unlock condition and the optional campaignId behavior. Every sentence carries useful information, and the field list is justified because there is no output schema.

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 there is no output schema, the description appropriately enumerates the return fields and explains hidden fields before unlock. With read-only annotations and fully described parameters, an agent has enough context 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?

Schema description coverage is 100%, so both parameters are already documented in the input schema. The description reinforces campaignId’s purpose but does not add format, constraints, or failure behavior beyond what the schema provides.

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 and resource: returns a creator’s profile. It enumerates the profile fields returned and makes clear it is distinct from discovery tools like search_creators by operating on a known creatorId.

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 indicates the primary use case—fetching a creator profile by id—and explains that campaignId optionally adds campaign-specific context. It also implies the relationship to unlock_creator by noting which fields remain hidden until unlock, but it does not explicitly name alternatives or when not to use this tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds two genuinely new traits: the operation is free and exempt from the daily search quota, and results are returned in the original stored ranking rather than re-ranked. It stops short of anything about persistence, expiry of old searches, or size of the returned set, so the addition is worthwhile but thin.

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

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

Two short sentences, zero filler, with the primary outcome (returns the search and ranked results) front-loaded ahead of the cost note. Nothing could be cut without losing 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?

With no output schema, the description carries the burden of describing the return value and does state that it returns the search plus its ranked results. Missing only edge-case behavior (deleted/expired search ids, result volume), which is a minor gap for a single-parameter read 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 searchId field already enumerates its sources (search_creators, find_similar_creators, list_searches). The description adds nothing about the parameter itself, so the baseline 3 applies.

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

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

States a concrete verb+resource ('Returns a past search and its results') and pins the ordering semantics ('in the order they were ranked, as search_creators returned them'). It is distinguishable from list_searches and search_creators by implication, but it never names the nearest sibling, so an agent must infer that list_searches only enumerates searches without results.

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

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

The 'Free, and does not count against the daily search limit' clause gives a real cost-based reason to prefer this over re-running search_creators, which is useful informal usage guidance. However, there is no explicit statement of when to use this versus list_searches or find_similar_creators, and no preconditions (e.g., what happens if the search id is stale or unknown).

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 readOnlyHint and openWorldHint=false annotations already establish this as a safe, closed-database read, so the description's main additions are that values reflect what is 'present in the database' (dynamic, corpus-dependent) and that the call costs nothing. It does not describe the shape or size of the response, and with no output schema that gap is left open.

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 naming the action followed by the enumerated value categories, plus a one-word cost note. No padding, 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 zero-parameter lookup with no output schema, the description carries the needed burden by listing what categories of values come back and noting they are drawn from live database contents. Details of the response structure (per-field shapes, ordering) remain unspecified, which is the only material 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, and the description correctly does not invent any, so there is nothing beyond the empty schema to clarify. Baseline 4 applies for a no-argument tool.

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: returns the accepted values for search and browse filters, then enumerates the axes (platforms, creator countries, languages, niches, activity windows). This clearly separates it from siblings like search_creators or browse_creators, which consume filters rather than enumerate them, though it never names an alternative explicitly.

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

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

Usage is implied rather than stated: an agent can infer this is the discovery call to make before constructing a search, and the trailing 'Free' hints it is safe to call speculatively. There is no explicit when-to-use/when-not guidance or named alternative, so it stays at minimum-viable.

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, so safety is covered. The description adds genuinely useful context beyond that: 'Free' (a zero-cost operation) and the existence of a default 'General Outreach' campaign, which affects how an agent interprets an empty or unfiltered result.

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, front-loaded with what the tool does; 'Free.' is a compact cost signal. No wasted text, though it is short enough that a little more guidance would have fit.

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, describing the shape of the result (brief, status, creator-stage counts) is exactly the right compensation, and the three params are fully covered by the schema. Minor gap: no pagination or result-size expectations, which matters for a list 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%, with all three params documented (page, limit, status enum). The description's mention of 'status' refers to a returned field rather than the filter parameter, so it adds no meaning beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Lists your campaigns') and even names the fields returned (brief, status, creator counts per stage). It doesn't explicitly distinguish itself from the sibling get_campaign_status, which could overlap, 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?

Usage is only implied: the agent infers this is the read tool for campaigns. There is no explicit when-to-use/when-not, no mention of how it relates to get_campaign_status or create_campaign, and no stated prerequisites.

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, so safety is covered. The description adds two genuinely new facts beyond annotations: the result ordering (most recently saved first) and that the call is free, but says nothing about pagination limits beyond the schema or what a returned creator record contains.

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

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

Two sentences, front-loaded with the resource and scope, with no redundant restatement of the title. The terse 'Free.' fragment is unusual but conveys a distinct, decision-relevant fact without 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?

For a simple read-only, zero-required-parameter list tool with full schema coverage and safety annotations, this is close to sufficient. The gap is that with no output schema, the description does not indicate what each saved creator entry includes or whether paging metadata is returned.

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% with clear descriptions for both page and limit including the default of 20, so the schema carries the parameter burden. The description adds no paging guidance or advice on using limit to bound results, so baseline 3 applies.

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

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

Specific verb ('Lists') plus a precisely scoped resource ('creators on the account's saved list'), which distinguishes it from browse_creators and search_creators by scope alone. It also states ordering ('most recently saved first'), though it never names a sibling for contrast.

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

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

The 'saved list' scoping implies when to use it (retrieving previously saved creators rather than searching), and 'Free' signals a cost advantage over credit-consuming siblings like reveal_contact or unlock_creator. However, no explicit when-not or named alternative is given.

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, so safety is covered; the description adds genuinely new behavioral context: result ordering, the fact that find_similar_creators runs appear in the history, and that calls do not consume the daily search quota. It stops short of describing the response shape or how pagination interacts with the newest-first ordering.

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

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

Two sentences, both front-loaded with the highest-value information (what it lists and its ordering, then the alternative tool). No redundant restatement of the title and 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?

With no output schema, the description correctly carries the return-value burden by naming the fields returned and their ordering. Pagination defaults and archived-search handling are delegated to the fully documented schema, so only minor gaps (no mention of total counts or empty-history behavior) remain.

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 page, limit, campaignId and includeArchived are already fully documented in the schema. The description adds no param-level meaning beyond that, which is the expected baseline when the schema does 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 and resource ('Lists the searches run before') plus the exact payload returned (query, filters, result count) and ordering (newest first). The scope note that find_similar_creators searches are included distinguishes it from the other list_* siblings that cover saved creators and campaigns.

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 away from re-running a search: 'To see a search's results again, call get_search instead of searching again.' It also gives a cost-based reason to prefer this tool (free, no daily-limit impact), though it never states an explicit when-not-to-use case such as excluding active or in-progress searches.

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 it is a non-destructive write with no open-world access; the description adds substantially more: it is free, it is idempotent ('Recording the same reply again changes nothing'), and each disposition has a distinct state effect (positive/neutral moves the creator to negotiation, negative declines and closes the conversation).

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 restriction and prerequisite are front-loaded and every sentence carries information. The clause about negotiation state ('a confirmed collaboration stays), waiting on the user') is slightly compressed and takes a re-read, but nothing is wasted.

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

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

With no output schema, the description still covers what matters for correct use: prerequisite email, exclusion of email replies, idempotency, and the state transitions produced by each disposition. Nothing an agent needs to invoke it safely 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%, so the baseline is 3; the description goes beyond the schema by explaining the downstream consequence of each disposition value, which the enum description alone does not convey. It adds nothing for price, liveWindow, or summary, but those are already well documented 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 ('records a reply') and immediately bounds the scope to replies that arrived 'some other way (a DM, another inbox, a call)'. It explicitly contrasts with the sibling path by naming get_conversation and warning against logging email replies, so an agent can tell it apart from the email/conversation 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?

Gives explicit when-to-use (off-channel replies), an explicit when-not (replies to emails sent with send_email arrive on their own, 'never record those'), a prerequisite ('Needs an email sent first'), and redirects to get_conversation for the excluded case.

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 readOnlyHint=false and idempotentHint=true; the description explains exactly why — it mutates state by adding the creator to the campaign and spending credits, and repeat reveals are free, which is consistent with idempotency. Credit costs and side effects are disclosed beyond the structured fields.

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

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

Three sentences, front-loaded with the return value, then the side effect and pricing, then the prerequisite for send_email. Every clause carries decision-relevant 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?

No output schema exists, and the description still names what comes back (the email address). With two fully documented params and annotations covering the safety profile, nothing an agent needs is missing.

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

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

Schema description coverage is 100% and both parameters are documented with their sources (search_creators, list_campaigns/create_campaign). The description only implies campaign scoping ('in this campaign'), so the baseline 3 applies.

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

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

States a specific verb and resource ('Returns the creator's email address') plus the scope ('in this campaign'), and distinguishes itself from send_email by declaring it a prerequisite. The 'adding the creator to the campaign first if needed' clause implicitly separates it from unlock_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 explicit conditions: use before send_email, use when you need the email, and reveals the cost trade-off (0.5 credits to add/unlock first time, 0.2 to reveal first time, free thereafter in any campaign). The agent knows both when to call it and what it will cost.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the bar is lower, but the description still adds real value: it discloses that saving unlocks the creator at 0.5 credits the first time and is free on repeat, which is a concrete cost side-effect an agent must know before calling. The consistency with idempotentHint=true is good; only error/duplicate handling is left unstated.

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

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

Three tight sentences, front-loaded with the action and destination before the cost and parameter advice. The parenthetical "(the dashboard's Saved page)" is slightly clunky but earns its place by anchoring the concept to a UI surface the user knows.

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 two-parameter mutation with full schema coverage and no output schema, the description covers the essential unknowns: what the saved list is, that it sits outside campaigns, the credit cost, and free repeat saves. Only duplicate-handling and the response shape are absent, which is minor given the annotations.

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 both parameters are documented in the schema already. The description adds modest meaning by framing searchId as provenance ("remember where they were found") rather than just a filter id, but creatorId gets no extra semantics beyond the schema's own pointer to search_creators results.

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 and resource ("Saves a creator to the account's saved list") and scopes it precisely as the user's own bookmarks outside any campaign, to the dashboard's Saved page. That separates it from campaign-oriented siblings in spirit, but it never names add_creator or unlock_creator explicitly, which is the main ambiguity for an agent choosing among the three.

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 implies when to use the tool by defining the saved-list destination and by noting the credit cost, and it gives one concrete usage instruction (pass searchId to remember where the creator was found). It stops short of saying when to prefer this over add_creator or unlock_creator, or what happens if the creator is already saved.

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 readOnlyHint/openWorldHint it discloses quota consumption, the key output limitation (names shown but no handle or profile link, implying another tool is needed for contact), that unfound example creators surface in warnings, and that campaignId causes the search to be ranked against and recorded in that campaign.

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 search mechanic, then secondary behaviors (limits, output limitation, campaign recording) in descending order of importance. Slightly redundant phrasing ("describe the creators you want in plain words" repeats the query schema text) keeps it from a 5, but every sentence carries 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 16-parameter semantic search with no output schema, the description covers cost, one output limitation, and the campaign side effect, which is solid. It does not describe what a result record contains (followers, engagement, platform) or result ordering/limit behavior, so an agent still lacks a full picture of the response.

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 all 16 parameters are already documented, and the description mostly restates the facet list (platform, niche, country, language, size, engagement, recency) rather than adding syntax or edge-case meaning. It does add intent framing for exampleCreators and campaignId, but that intent is largely mirrored in the schema descriptions, so the baseline 3 fits.

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 ("Searches the creator database by meaning") and immediately explains the input mode: describe creators in plain words, optionally narrowed by facets. It is clearly distinguishable from siblings like get_creator (single lookup) and from non-search tools such as list_campaigns.

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

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

Gives explicit conditions for the two interesting paths: use plain-word query for discovery and pass exampleCreators "to find creators like ones the user already knows." It also states the cost model (free but counts against the daily search limit) and points to get_account for the limit. It stops short of naming when to prefer get_creator or unlock_creator instead, so no full 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?

Discloses meaningful behavior beyond annotations: replies arrive in the conversation, daily free-email limits and credit costs apply, and repeat sends are deduplicated unless a new idempotencyKey is supplied. This is consistent with annotations and adds important operational context for a write 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?

The description is front-loaded with the core action and remains compact while covering prerequisites, replies, costs, and idempotency. Every sentence adds relevant context for correctly invoking the tool.

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 the absence of an output schema, the description covers the important context an agent needs: prerequisite contact reveal, where replies appear, cost/limit behavior, and idempotent retry semantics. It is complete enough for correct use.

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

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

Schema coverage is 100%, so the schema already documents the parameters well. The description adds useful semantic detail for idempotencyKey and explains that the email goes to the creator’s revealed address, though it does not add much beyond schema for subject, body, or campaignId.

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: sends a plain-text email to a creator’s revealed address. It also distinguishes the tool from siblings by naming reveal_contact and get_conversation, so an agent can tell exactly what this tool does.

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

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

Explicitly says to call reveal_contact first before using this tool and points to get_conversation and get_account for related context. This gives clear prerequisites and routing to alternatives instead of leaving usage 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 declare readOnlyHint=false and idempotentHint=true, and the description adds the crucial non-annotation detail of credit consumption and its repeat-free behavior, plus the scope limit on email. It does not say what happens on an invalid or already-deleted creatorId, but the expensive/irreversible aspects an agent needs are covered.

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: what it returns, what it costs, and what it does not do. Each sentence carries distinct decision-relevant information with no repetition of the title or schema.

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 compensates by enumerating the returned fields, and it covers the two things an agent would otherwise get wrong: the credit charge and the email omission. For a one-parameter, non-destructive tool this is complete.

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

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

Schema description coverage is 100% for the single creatorId parameter, and the schema already states it comes from search_creators results. The description adds no further meaning such as format or failure modes for the id, 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 ('Unlocks the creator') and enumerates the payload ('handle, profile link and recent video titles and links'), which is far more informative than the title alone. It does not differentiate itself from the sibling get_creator, leaving ambiguity about what that tool returns versus what unlocking adds.

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 cost guidance ('0.5 credits the first time for each creator; unlocking again is free') and an explicit exclusion with a named alternative ('It does not reveal the email address; use reveal_contact for that'). Missing is any statement about when to choose this over get_creator or search_creators.

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=false, destructiveHint=false, and openWorldHint=false, so the safety profile is largely covered by structured data. The description does add genuinely useful scope beyond that: the action costs nothing and leaves the creator unlocked and in existing campaigns, which tells the agent precisely which side effects do NOT occur. With annotations carrying the burden, this is a modest but real addition.

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, action first, side-effect caveats second, with zero filler. Every clause ('Free', 'stays unlocked', 'in any campaign') carries information the 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, non-destructive mutation with no output schema, the description covers cost and persistence of unlocks and campaign membership, which is the main ambiguity. It leaves minor gaps such as behavior when the creator is not currently saved or whether the call is idempotent, but these are secondary.

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 documented as 'Creator id, from search_creators results', so provenance is already supplied by the schema. The description adds no format, ID-type, or lookup guidance beyond that, so the baseline 3 applies.

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

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

States a specific verb ('Removes') and resource ('a creator from the account's saved list'), which cleanly marks it as the inverse of the sibling save_creator and distinct from exclude_creator or list_saved_creators. It stops short of naming a sibling explicitly, so the differentiation is inferred from naming symmetry rather than stated.

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

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

Usage is implied by the phrase 'saved list' and the paired save_creator tool, but there is no explicit when-to-use guidance or when-not guidance against adjacent tools like exclude_creator (which likely also removes a creator from working sets) or removing a creator from a campaign. The 'Free' note hints at a cost trade-off with unlock_creator but doesn't frame it as a decision rule.

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 annotations (which only declare non-read-only, non-destructive, closed-world) by disclosing that the call is free, that a new brief becomes the next revision, that searches with this campaignId will rank against it thereafter, and that existing creators stay in the campaign. Those are the non-obvious side effects an agent needs before mutating live campaign data.

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

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

Two sentences, front-loaded with the affected fields, then a compact block of consequences. No filler and no repetition of schema detail.

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?

Covers the mutation's side effects, cost and partial-update rule thoroughly for a 5-parameter tool with no output schema. What it omits is the response shape and any indication of validation failures, which is acceptable given no output schema is declared but leaves a small gap.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds real semantic value by explaining that brief updates cascade into revision history and search ranking, and that unchanged fields should be omitted rather than resent. It adds no extra meaning for status or archived beyond the schema's own descriptions.

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

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

Names a specific verb and resource plus the exact mutable fields (name, brief, status, archived), which cleanly separates it from create_campaign, get_campaign_status and list_campaigns. An agent knows immediately this is the partial-update path for an existing campaign.

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?

"Pass only what changes" gives the key PATCH-style usage rule that prevents accidental overwrites, and the field list implies the scope. It does not explicitly route away from siblings or state prerequisites such as needing an existing campaignId, so it falls short of an explicit when/when-not statement.

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=false, destructiveHint=false, openWorldHint=false), and the description adds two things beyond them: that archiving is reversible via archived:false, and that the operation is 'Free' (a cost signal not encoded anywhere in the structured fields). It does not say what happens if both name and archived are omitted, which is the remaining behavioral gap.

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

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

A single sentence with the primary action front-loaded, the archive side effect second, and the undo path in parentheses. Every clause carries information; nothing is redundant 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?

For a three-parameter, non-destructive mutation with full schema coverage and no output schema, the description covers both modes, the side effect on list_searches, the reversal path, and cost. Only the no-op case (neither name nor archived supplied) and the refresh-after-update expectation are left unstated.

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

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

Schema description coverage is 100%, so all three parameters are already documented, including the archived reversal semantics that the parenthetical restates. The description adds no syntax, length, or conflict guidance (e.g., whether name and archived can be combined in one call), so it sits at the baseline rather than above it.

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 set (rename / archive) against a specific resource (a past search), and ties the archive behavior to the sibling that exhibits it (list_searches). An agent can distinguish this from get_search or list_searches without opening any schema.

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

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

Usage is implied rather than stated: the parenthetical '(archived: false brings it back)' tells the agent how to undo an archive, which is a genuine when-to-use hint. But there is no explicit guidance on when to call this versus get_search, list_searches, or other update_* tools, and no prerequisites (e.g., ownership) are mentioned.

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