ProductClank

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

Annotations only clarify that the tool is not read-only, not destructive, and not open-world. The description adds that the effect is granting view/manage access, but it does not mention possible side effects like repeated calls creating duplicate delegates, account/permission prerequisites, or whether an existing delegate is replaced. That is an adequate baseline but not a rich behavioral disclosure.

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 deliver the action, outcome, cost, and target use case efficiently. The one-word fragment 'Free.' carries relevant economics without detracting from the overall structure.

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 only two simple string parameters and no output schema, the description covers the required context: what the tool does, who it can add, and when it is useful. It lacks details about return values or error cases, but these are less critical for this call shape.

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 50% schema description coverage because campaign_id lacks a schema description, the description compensates by referring to the campaign and calling it 'agent-created'. For user_id, the description adds beyond the schema by noting that the connected user's own id can be used. This meaningfully helps an agent choose parameters correctly.

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: 'Add a ProductClank user as a delegate on a campaign', with a clear outcome ('so they can view and manage it from the webapp's My Campaigns page'). The title reinforces the primary effect, and no sibling tool overlaps with the act of granting delegate access.

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: 'Useful to hand oversight of an agent-created campaign to its human owner', and even covers the edge case of self-delegation ('the connected user's own id works too'). It does not name alternatives, but there are no obvious sibling tools dedicated to this task, so exclusions are less necessary.

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 provide readOnlyHint=false and openWorldHint=true, and the description adds substantive behavior on top: the '3 credits, charged only when a brief comes back' cost model and the explicit no-side-effect guarantee ('Creates nothing — no campaign, no product, no discovery'). This is exactly the cost and mutation context an agent needs and that annotations do not supply. No contradiction with the annotations.

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

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

The description is longer than average but every sentence earns its place: purpose first, then cost, then side-effect guarantee, then when-to-use, then usage workflow. The front-loaded purpose and the clear escalation in emphasis make it well structured, with only minor redundancy around the credit note.

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 complexity (external web read, cost, no output schema), the description covers everything an agent needs: when to use it, what it returns (8-15 keywords, suggested title, search_context), how to process the result (cut to 3-8 keywords), and the cost condition. The absence of an exact return-structure spec is minor given the workflow guidance provided.

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 schema descriptions are already rich (platform enum with vocabulary explanation, product_id with its sharpening effect). The description adds modest value by tying the output (keywords/search_context) to create_campaign and implying how platform influences output, but does not meaningfully deepen per-parameter meaning beyond the schema. Baseline 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 opens with a specific verb+resource: 'Read a product's website and propose the two fields create_campaign requires.' It names the exact deliverable (keywords, search_context, plus a suggested title), which makes the tool's function unambiguous and clearly positioned relative to the create_campaign sibling.

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?

Exceptionally explicit: 'USE THIS ONLY WHEN YOU CANNOT FETCH THE PAGE YOURSELF' states the primary condition, and the description further differentiates from in-conversation derivation (free, iterable, audience-aware) and gives the fallback trigger ('web access is unavailable or the fetch failed'). It even instructs the agent to disclose the credit cost before calling.

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 it is non-read-only, non-destructive and open-world; the description goes far beyond that by disclosing the credit cost per action, the concrete billing math, per-platform capability limits, the TikTok caption-timing behavior and the resulting waiting_for_post_text state, and the fact that watch_quiz billing is separate from credits_used.

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 purpose is front-loaded, which is good, but the body is a single sprawling multi-clause block of em-dash-separated facts. Nearly every detail is useful in isolation, but the packaging is dense and hard to scan, so it earns only a middling score.

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 credit-spending mutation with a nested watch_quiz object and no output schema, the description covers cost, platform eligibility, pacing, deferred-charge behavior and a named result state. An agent has everything it needs to call it correctly and to warn the user about spend.

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

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

Schema description coverage is 100%, so the baseline is 3. The description largely restates the schema's own cost tables for count and repeats the platform restrictions already in action_type's enum description; only the physical explanation of a 'quote' post being the highest-reach action adds meaning beyond the structured field.

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

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

The description gives a specific verb and resource ('Creates a boost campaign'), names the concrete effect (spends the user's credits) and enumerates the distinct action types. It also references siblings (search_products, create_product, create_watch_quiz), letting an agent place it precisely in the toolset.

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 conditional guidance for choosing between action types, platform support, immediate vs paced delivery, and explicitly instructs the agent to confirm the action and cost with the user before calling. It lacks an explicit 'use this instead of create_campaign/regenerate_replies' routing statement, but the surrounding context 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 already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered. The description adds genuinely new context: the call is free, the data is scoped to 'the connected user', and it explains the pay-per-action pricing model (every tool works if balance covers it; plans are just a cheaper rate). It does not mention auth requirements or rate limits, keeping it below 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?

Front-loaded with 'Free.' then the payload, then the usage directive, then the pricing-model clarification. Sentences are dense and each carries content, though the trailing 'Typical costs' list and ALL-CAPS emphasis make it feel run-on rather than crisp.

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

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

No output schema exists, so the description must describe return values — and it does, covering balance, plan, per-action pricing, plays, packs, and plans. The included example costs (campaign 1000, boost 200, discovery 10+12) make it self-sufficient, though hardcoded figures risk going stale and no format details (credits units vs dollars) are spelled out beyond 'dollar range'.

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

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

Zero parameters, so the baseline is 4. The description does not need to explain inputs, but it usefully orients the agent to the response structure (pricing.plays, top-up packs, plans) rather than overclaiming parameter detail.

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 connected user's credit balance and plan) and additionally enumerates the concrete payload: per-action credit costs, dollar ranges, plays priced at test/standard/scale, top-up packs and plans. An agent know exactly what this returns without opening anything else, and it is distinct from siblings like credit_history or get_earnings.

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 invocation timing: 'Call it before planning or recommending any spend, and quote these prices — never guess or look them up.' That is clear, actionable guidance. It stops short of naming alternatives (e.g. credit_history for past transactions) or stating when-not to use it, so it lands at 4 rather than 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 this is a non-destructive, non-read-only, idempotent, closed-world mutation, so the bar is lower. The description adds genuinely useful behavior beyond that: a 72-hour hold window, zero cost ('Free'), the re-claim refresh semantics, the explicit fact that the agent never posts, and the 409 conflict meaning. Minor residual tension: 'Claiming again refreshes the hold' is a repeated-call side effect on the hold expiry, which sits slightly awkwardly beside idempotentHint=true.

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

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

Front-loads the core action and its constraint (72-hour hold, no competing replies) before the price, the workflow routing, and the error case. Every sentence carries operational information; none is restatement of the name or 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?

There is no output schema, but the description compensates by enumerating the return payload (post link, drafted opener, scout's links) and the full downstream workflow. Combined with annotations covering safety, an agent has everything needed to call this correctly and act on the result.

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 dealId parameter is fully documented in the schema as coming from get_scout_deals, so the baseline of 3 applies. The description adds indirect context (the deal belongs to 'this scout' and re-claiming targets the same deal) but no new syntax or format detail.

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 ('Hold a deal for this scout for 72 hours') and immediately clarifies the effect on other scouts replying to the same founder. It is clearly distinguishable from siblings like release_deal, report_deal_progress, and get_scout_deals, which are either named in the workflow or implied by 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?

Gives explicit timing ('Call it when the user decides to reply, BEFORE they post') and routes the agent to the follow-up tool with the exact argument ('report_deal_progress with stage 'sent' and the reply URL'). It also covers the failure path: '409 claimed_by_another_scout = someone else holds it; pick another deal.'

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 readOnly=false/openWorld=true/destructive=false, but the description adds rich behavior: 10-credit create cost, separate 12-credit/post billing, private is reversible and free while public bills per network-posted reply, server-side REJECTION of platform-mismatched params (target_subreddits/target_youtube_channels), Reddit's one-reply-per-subreddit-per-day limit, and the ~30s background research. This is well beyond what structured fields convey.

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

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

Very long, but front-loaded (purpose first, then BEFORE-calling prep, costs, private/public modes) and every block carries distinct information with no obvious filler. Density is high enough to justify the length, though the run-on 'BEFORE calling' sentence could be tightened.

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 mutation tool with no output schema, the description covers cost, defaults, prerequisites, the private/public decision, the decision_offer relay, and cross-tool dependencies (get_research, generate_posts, setup_content_space). Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is already 94% (baseline 3), but the description adds real semantics: keywords and search_context are the agent's to derive from the site, the mention_accounts vs reply_tag_accounts split, space_id's fallback to the oldest space, and platform being fixed after first discovery. Useful additions beyond the schema, though most field details still live 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?

Opens with a specific verb+resource+behavior: 'Create a Communiply discovery campaign: it continuously finds relevant social posts (by keyword) and drafts replies for them.' This clearly distinguishes it from the sibling create_content_campaign and from update_campaign/get_campaign, so an agent knows exactly what this tool produces.

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

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

Explicit when-to-use and how-to-prepare guidance: derive keywords/search_context before calling, use search_products/create_product for product_id, default to private unless the user says otherwise, ask about reply_approach on X, pick the platform the audience is on, and confirm credit cost first. It also names alternatives (generate_posts for the paid discovery step, get_research before spending), leaving little 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, destructiveHint=false, and openWorldHint=false, so the core safety profile is already clear. The description adds that the tool spends 1000 credits (a critical behavioral trait not in annotations), and auto-activates the campaign. However, it does not mention whether the action is reversible, what happens to unused credits, or if there is a confirmation step beyond user prompt. With no destructive hint, the description could more explicitly state that this is a write-only action that cannot be undone.

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 compact (4 sentences), front-loads the core purpose, and each sentence adds distinct value: what the tool does, credit cost, automation behavior, prerequisites, and usage steps. No wasted words.

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 7 parameters (2 required), no output schema, and moderate complexity, the description covers the core workflow (prerequisite, preview, cost, activation). It is complete enough for an agent to use correctly. Minor gap: it does not mention what happens after activation (e.g., how to track results), but the description 'community submissions and winner selection happen in ProductClank web app' provides sufficient closure.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds that campaign_message is a 'core brief' and that the AI expands the brief, but does not explain how other parameters like references or additional_guidelines interact. It does not add syntax or domain-specific details beyond what the schema already provides. Overall, the description adds marginal value over the schema.

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

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

The description clearly states the verb ('launch') and resource ('content campaign'), and specifies the unique scope: rallying a community to create content (posts, threads, videos). It differentiates from siblings like suggest_content_campaign (preview) and boost_post (separate action), and explicitly mentions the required product_id from search_products.

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

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

The description explicitly recommends using suggest_content_campaign for preview first and confirms the 1000-credit cost before calling. It also states the need for a product_id from search_products. However, it does not explicitly state when not to use this tool or compare to other siblings like write_content_candidates, which could be an alternative for creating content.

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 indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds significant behavioral context: it is free ('FREE — no credits charged'), it auto-fills fields from the URL with override behavior, it deduplicates ('reuses an existing listing... rather than duplicating'), and it returns the product id. No contradiction with 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?

The description is concise (few sentences), front-loaded with the core purpose, and each sentence adds unique value. No redundancy. It efficiently covers purpose, usage, behavior, and parameters without wasted words.

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 tool's complexity (8 parameters, no output schema, but 100% schema coverage), the description covers all crucial aspects: what it does, when to use it, the auto-fill mechanism, dedup behavior, free nature, and return value (product id). It also warns about confirming with the user. No gaps remain for effective invocation.

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 8 parameters all described. The description goes beyond by stating that 'At minimum pass a url' and that 'the server auto-fills the name, tagline, description, logo, and X handle from the site; any field you pass explicitly overrides what's extracted.' This adds semantics about parameter relationships and defaults that are not in the schema, making it highly informative.

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 clearly states the tool's action ('List a new product on ProductClank') and its key characteristic ('token-free listing'). It also distinguishes itself from the sibling tool 'search_products' by specifying the use case ('when search_products finds no existing match'). The verb 'list' combined with the resource and context makes the purpose explicit.

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

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

The description provides explicit guidance: 'Use this when search_products finds no existing match and the user wants to run a boost or campaign for a product that isn't listed yet.' It also instructs the agent to 'Confirm the product details with the user before calling,' giving a clear prerequisite. This effectively contrasts with siblings like 'boost_post' (which requires an existing product).

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 readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description goes far beyond: public visibility, exactly 24-hour lifetime, retry-once behavior, the credit cost model (100 credits per correct answer, paid for 24h, capped by max_answers), a 100-credit balance prerequisite, and a compliance warning that paid watch time may count as artificial engagement. This is exactly the behavioral context annotations cannot 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-loaded with the value proposition and mechanics, then cost, then the pre-call checklist, then the sibling routing note. Dense but every clause is functional; the only mild cost is length in a single paragraph.

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 cost, duration, visibility, prerequisites, retry semantics, failure/bypass guidance (suggest_quiz_questions), and a user disclosure note. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is already 100%, so baseline is 3. The description adds real value on top: it explains the max_answers spend arithmetic, that duration_sec can be omitted for TikTok/YouTube but is required elsewhere, and that questions must come from the user since the agent cannot watch the video.

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 ('Create a watch quiz') plus the exact mechanics: viewers watch full length, answer one counting question, right answer earns points, wrong first answer gets a retry. It also distinguishes itself from the sibling boost_post's embedded watch_quiz, so an agent can route correctly.

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

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

Explicit pre-call checklist: 'get the questions AND answers from the user (or run suggest_quiz_questions and have them confirm), and confirm max_answers and the maximum spend.' It also names the alternative ('To add a quiz to a boost of the same video, use boost_post's watch_quiz instead'), so both when-to-use and when-not are covered.

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

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

The description accurately states read-only behavior, which matches the readOnlyhint annotation, and adds useful behavioral details beyond it: free, newest-first ordering, types of transactions included, and the fact that in-connector top-ups are unavailable. It does not contradict the annotations, but it also does not go deep into response shape or edge behaviors.

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, purposeful sentences, each doing useful work: one states what the tool is, one states its intended use, and one gives the key out-of-band transaction steps. The description is front-loaded with the primary identity and does not waste words.

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 two self-describing optional params and the very helpful readOnlyhint annotation, the description covers the main things an agent needs: what data it affects, why to call it, and the external fallback to a purchase URL. It does not go into output shape, but because there is no output schema, listing transaction categories and order is reasonably complete for this simple history 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 two params are optional limit and offset, whose names are fairly self-descriptive. The schema documents the limit default and bounds, leaving offset semantics implicit. The description's 'newest first' adds context for reading the list but does not explain pagination, so the description adds only marginal value beyond the schema.

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

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

The description clearly states that this returns the connected user's credit transactions (purchases, campaign spend, participation rewards), newest first. It is specific about the resource and ordering, and it is easy to tell apart from siblings like check_balance, though it does not explicitly name an alternative tool for the same purpose.

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

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

The description says to use it to account for spent or earned credits, which gives a clear intended use case. It also tells the caller that top-ups are not available in-connector, routing users to an external purchase URL when balance runs low. It does not explicitly address when check_balance should be used instead, but the usage guidance is still reasonably 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses an important refusal condition (already_claimed), platform character limits, and that the edit becomes what gets posted. It does not address errors or persistence details, but the main behavioral risks 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?

The description is three sentences, front-loads the core action, and every sentence carries distinct information: what it edits, when to use it, and constraints/refusals. No filler or repetition of the 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?

For a simple three-parameter mutation tool with minimal annotations and no output schema, the description supplies enough context to invoke it correctly, including a key failure condition and length limits. The only minor gap is that campaign_id is not explained, but this is shared campaign context rather than tool-specific 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?

With two of three parameters described in the schema, the description adds meaning by tying reply_id to get_posts, framing reply_text as a full replacement, and adding X/other character limits. The campaign_id parameter remains undocumented, but the context is mostly recoverable from the campaign workflow.

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 ('Rewrite the text of ONE reply draft') and clarifies scope with 'before the community posts it' and 'exact reply a creator will claim.' This distinguishes it from generation/publishing siblings without needing to open 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?

'Use it when the user wants different wording on a specific draft from get_posts' states the triggering condition explicitly, and 'Refuses a reply a creator has already claimed ... edit before you publish' provides a clear when-not-to-use constraint. This gives an agent actionable 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 declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with 'Free, read-only' plus rich behavioral detail the annotations cannot carry: the two kind categories, what 'human_only' participation means, reward availability, and the crucial constraint that the user performs watch quizzes and the agent never submits 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?

Front-loaded with what the tool discovers, then the item taxonomy, then the quiz handling, then the follow-up step. Dense but every sentence carries operational information; it is slightly long, costing it the top mark.

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

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

No output schema exists, so the description bears responsibility for return-value context, and it does describe item shape (kind field, participation value, watch_quiz.quiz_url / how_to_participate). It omits pagination/limit behavior, but nothing essential for 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 coverage is 100% with only two params, so baseline is 3. The description goes beyond the schema's terse 'Filter by campaign kind' by defining the semantics of each enum value ('content' = create a post/thread/video, 'take_action' = concrete action with proof), adding real meaning for the filter.

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 (find/discover) and a precise resource scope: every active public campaign plus campaigns from communities the user belongs to. Distinguishes itself from creation siblings (create_campaign, create_content_campaign) and single-campaign reads (get_campaign) by describing discovery for the connected user.

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 workflow context ('Follow with get_campaign_brief before doing any work') and prescribes the exact handoff for watch quizzes via watch_quiz.quiz_url. However, it never names the sibling it is not (e.g. list_campaigns) or states when not to use it, so the routing guidance is strong but not exhaustive.

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

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

Annotations only cover readOnlyHint and openWorldHint; the description adds substantial context beyond them: the listing excludes drafts held by other members, the user's own live hold carries `heldUntil`, holds are exclusive and single-slot, and the user must have that platform's handle linked on their profile for attribution. These are exactly the operational constraints an agent needs and none are in the schema.

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

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

A single dense paragraph, but it is front-loaded: what the tool returns comes first, then the workflow, then the caveats. The actionType and flow sentences are long but each carries unique information; only the platform list (X, Reddit, YouTube, LinkedIn) is marginally expendable.

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

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

No output schema exists, and the description compensates by describing the shape of each returned item (post + draft text + platform + actionType) and the heldUntil field. Combined with the workflow and eligibility caveats, an agent has everything needed to call this and interpret the result.

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% — `limit` and `campaign_id` are documented, `offset` is not. The description never mentions limit, offset, or campaign_id, so it adds no meaning beyond the schema. Baseline 3 applies since the schema does most of the work, but the undocumented pagination parameter is left entirely to inference.

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 ('Browse unclaimed drafts from active campaigns the connected user can earn from') and then defines exactly what an item contains: a real social post, pre-drafted text, `platform`, and `actionType` with both enum values explained. This is clearly distinguishable from siblings like find_open_campaigns (campaigns, not drafts) and get_posts.

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 end-to-end flow naming the sibling tools and their trigger conditions: pick an opportunity → hold_opportunity (10-minute hold, one at a time) → post → submit_participation with the URL. It also states an exclusion — likes and reposts are proved by screenshot and stay in the web app — which routes the agent away from this tool for those cases.

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 confirm side effects (readOnlyHint=false) and open-world interaction, but the description enriches this with concrete behavioral specifics: 12 credits per post, typical 5–20 posts, a few minutes duration, and the need to confirm the cost with the user. These are genuinely useful and not present in structured 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?

The description is three tight sentences that front-load the core operation, then give the critical cost and workflow details. No sentence is wasted, and the length matches the needed complexity.

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 state-changing, cost-incurring tool with no output schema, the description covers the full critical path: what it does, cost, time, user confirmation, and which sibling tools to use for reading and pruning results. Nothing essential for 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?

The schema lists only campaign_id with zero description coverage. The description's phrase 'the campaign's discovery pipeline' implies campaign_id identifies which campaign to use, but it does not explain the parameter further, its expected format, or where to obtain it. Some meaning is added, but at 0% schema coverage the description could compensate more.

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 clearly states the tool runs the campaign's discovery pipeline, scrapes social platforms for matching posts, and drafts community replies. This gives a specific resource and action that distinguishes it from later reading (get_posts) and pruning (review_posts), even though it does not explicitly name alternative discovery tools like find_opportunities.

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

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

It explicitly tells the agent to check_balance first, confirm the spend with the user, and then follow with get_posts and review_posts. This is clear contextual guidance on prerequisites and follow-up actions, but it does not explicitly state when not to use the tool or compare with alternate discovery/research tools.

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

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

Annotations already establish read-only and closed-world, so the description's added value is the cost disclosure ('Free') and the return content (posts discovered, replies by status) — real behavioral context an agent can act on. It does not mention auth requirements or pagination/limits, keeping it below 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?

Front-loads what is returned and ends with the when-to-use cue, with no filler sentences. The parenthetical enumeration of reply settings is dense and slightly run-on, 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 single-read tool with annotations covering safety and no output schema, the description adequately summarizes both config and stats payloads and the workflow position. Additional detail on stat formats or failure modes would round it out.

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?

Single parameter with 100% schema description coverage; the schema already states campaign_id is a UUID from list_campaigns or create_campaign. The description adds no extra syntax or sourcing detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (get) and resource (one campaign) and enumerates the configuration surfaces returned (keywords, search context, reply settings, reply_approach, reply_tag_accounts) plus live stats. This clearly separates it from list_campaigns, get_campaign_results, and get_campaign_activity.

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 triggering contexts: 'after generate_posts' and 'before adjusting the campaign', and labels the call as free. It stops short of naming an explicit alternative or when-not-to-use condition, so it is strong context rather than full routing guidance.

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

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

Annotations provide readOnlyHint=true and openWorldHint=false, but the description adds meaningful behavior: 'Free, and it never scrapes — safe to call at the start of every session.' It also discloses the default time window (last 24 hours) and the incremental behavior via `since`. No contradiction with 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?

Three tight sentences: purpose first, then safety/usability, then usage pattern. Every sentence earns its place with no fluff. The most critical info (incremental cursor) is front-loaded with `since`. Perfectly structured for quick agent scanning.

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 3-param tool with no output schema, the description gives a clear overview of return content (posts, replies, links, engagement), usage scope (across chats), and a pointer to the cumulative sibling. Combined with readOnlyHint, an agent has everything needed to call it correctly and integrate it into a multi-step workflow.

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 covers 2 of 3 parameters (67%), but the description enriches `since` significantly by tying it to the previous call's `checked_at` and explaining omit behavior. The missing campaign_id is self-evident. Since the description compensates for the gap and adds real semantic depth, it earns 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 and resource: 'Catch up on a campaign since the last check' and enumerates the exact return content (posts, replies, LIVE links, engagement). It clearly distinguishes from siblings like get_campaign_results by naming it explicitly for cumulative data, making purpose 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?

Explicitly says to use this to resume a standing growth operation across chats, then get_campaign_results for the cumulative picture. Also advises calling at the start of every session and explains how to use `since` for incremental checks. Clear when/why and points to an alternative.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description corroborates with 'Free, read-only' rather than contradicting. Beyond the annotations it adds meaningful context: external instruction files that should be fetched and followed, and the human_only participation branch with its own verification status field. It does not cover error/pagination behavior, but for a read tool with annotation coverage this is strong.

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 correctly with what the brief contains, but the back half drifts into instructions for sibling tools (submit_campaign_work, watch_quiz.my_status) that arguably belong in those definitions. The exception clause is valuable yet verbose relative to a single-parameter read 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?

There is no output schema, so the description must explain return content, and it does so thoroughly – action message, brief sections, judging criteria, rewards, deadline, and remaining submission count. It also covers the branching participation modes, leaving no material gap for calling 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?

Single required parameter with 100% schema description coverage ('Campaign id from find_open_campaigns'), so the schema already carries the semantics. The description implies but does not restate the id requirement or its provenance, so this sits at the baseline for a fully documented 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?

Names a specific resource (the full participation brief for one campaign) and enumerates its contents: action message, brief sections, content types, eligibility/selection criteria, rewards, deadline, remaining submissions. An agent can distinguish this from get_campaign or list_campaigns directly 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?

Prescribes the full downstream workflow: fetch and follow external instructions, create content WITH the user, then call submit_campaign_work with proof. It also names the exception path (human_only → hand the user watch_quiz.quiz_url and steps) and explicitly states nothing is submitted in that case, so the agent knows when not to use the normal flow.

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 description is not required to repeat safety. It adds value by disclosing that the tool is free and never scrapes, and that it costs nothing to poll, which informs an agent about rate-limit or cost implications. This goes beyond the annotations and provides useful behavioral context without contradiction.

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 thorough and well-structured, front-loading the funnel details and then the cost/usability question. It is slightly verbose but every sentence adds meaningful information—the funnel stages, metrics, cost breakdown, and usage context. It does not waste words on redundancy, so it earns a 4.

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

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

For a read-only reporting tool with a single parameter and no output schema, the description is quite complete. It enumerates all the data points the agent can expect, explains the cost model, and gives a usage scenario. The only missing piece is an explicit statement about the required campaign_id parameter and its format, but the rest is sufficient for an agent to call 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 coverage is 0% (the schema has no descriptions for parameters), and the description does not mention the campaign_id parameter at all. Although the parameter is self-explanatory from its name, the description fails to compensate for the lack of schema documentation. The agent would have to infer that campaign_id refers to the target campaign ID, which is a gap given the low coverage.

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 exactly what the tool does: it returns a cumulative scorecard for a campaign, enumerating the full funnel and metrics (approval rate, survival, engagement, credits spent, cost per usable reply). This is a specific verb+resource and is clearly distinct from the sibling tools, despite not naming them directly. The phrase 'unlike the web report' hints at an alternative without explicit differentiation, but the purpose 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?

The description provides a clear use case: 'Use it to answer "is this working and what am I paying for it?"' which guides when to call it. It also contrasts with the web report for cost and scraping behavior. However, it does not explicitly state when not to use it or name specific sibling alternatives, so it lacks explicit exclusions but is still helpful.

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, but the description adds real behavioral context: 'free' (no cost), safe to poll, and the transient 'processing' state with zero submissions immediately after launch. That post-launch state guidance is the kind of trait annotations cannot express, though return shape/pagination semantics are not 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?

Front-loaded with what the tool produces, then the safety/cost note, then the interpretive caveat about 'processing', and finally accepted identifier forms. Four sentences, each carrying distinct information with no wasted phrasing.

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 (submission counts, live links, review states, winners), and it covers the 4-parameter surface via 100% schema coverage. An agent has enough to call it correctly and interpret a fresh-campaign result.

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 limit, offset, status, and campaign_id are already fully documented in the schema. The description's note that it accepts a UUID or public campaign number largely duplicates the campaign_id schema text and adds no syntax or format detail the schema lacks; baseline 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?

States a specific verb and resource and enumerates exactly what it returns (submission counts, live content links, approval/rejection state, winners), which is more than the name or title conveys. It also distinguishes itself from the sibling get_campaign_results by anchoring to 'content campaign' and tying to create_content_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?

Gives clear usage context: use it to close the loop on create_content_campaign, it is safe to poll, and the 'processing' + zero-submissions state right after launch is expected rather than a failure. It does not explicitly state when not to use it or name a competing sibling to route to, so it stops 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds useful behavioral context beyond annotations: the tool is FREE, and it explains what each status value means including the default 'active'. It does not mention pagination or empty-queue behavior, but this is minor given the read-only nature.

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 purpose and return contents, then usage contexts, then status semantics. It is somewhat long but every sentence adds value; the status enumeration is informative rather than filler.

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

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

For a simple read tool with no output schema, the description covers the main return fields, intended use cases, cost implication (FREE), and status semantics. Missing details like default limit, ordering, or how to interpret verdict are not critical but would make it fully 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 0%, so the description must compensate. It does a good job explaining the 'status' parameter, including the default and each enum value's meaning. However, it does not explain the 'limit' parameter's semantics or default behavior, and 'space_id' is left entirely to its name and the schema's required marker.

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 clearly states a specific verb and resource: reading the space's content queue, and enumerates the returned fields (text, platform, status, reviewer score/verdict/fix). It also differentiates itself from siblings by framing this as the user-facing 'All Content' view and explicitly connecting to write_content_candidates, making its role distinct from other getters.

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

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

The description explicitly says when to use it: to present drafts for approval one by one and to read back scores after write_content_candidates. It does not provide when-not-to-use guidance or name alternative tools, so it stops short of the top tier.

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 the readOnlyHint annotation, the description discloses that the tool is FREE, lists the content of the workspace, and explains the meaning of enabled:false—that the space has no content engine yet. This gives the agent actionable behavioral knowledge about how to interpret the response.

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 three sentences with no filler: it front-loads the return contents, then adds the FREE signal and usage guidance, then the key enabled:false branch. 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?

For a simple single-parameter read tool with no output schema, the description is complete: it tells the agent what data will come back, when to retrieve it, and how to interpret the critical enabled flag. No essential behavior is missing.

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

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

Schema description coverage is 100%, and the single parameter space_id is already documented as coming from list_content_spaces or any Amplify space the user owns. The description adds context about the workspace contents but does not need to add parameter-level detail. Baseline 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 opens by naming exactly what the tool returns: the brand's voice, platforms, post types, playbook, review threshold, topic inventory, and style guides for one content space. This clearly distinguishes it from siblings like list_content_spaces (listing spaces) and setup_content_space (creating/updating a space).

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

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

The description explicitly says to read this BEFORE writing any draft and at the start of any content conversation. It also provides a conditional follow-up: if enabled:false, offer setup_content_space, which tells the agent when not to proceed with writing and what sibling to invoke instead.

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 the readOnlyHint=true annotation, the description adds 'Free' and explicitly repeats 'read-only' with the phrase 'Free, read-only.' It also clarifies scope (connected user, work submitted via this connector) and the exact data categories returned. No contradiction with 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?

A single, well-structured sentence is front-loaded with the main deliverable ('participation totals') followed by a compact list of the exact data elements. Every phrase earns its place — no filler, no repetition of the title beyond the core verb.

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

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

The tool is a simple 0-parameter read-only operation with no output schema. The description fully covers purpose, scope, return contents, cost, and safety. Nothing an agent needs to decide when to call it and what it will receive 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 has zero parameters and the schema coverage is 100% with no required fields, so the description carries no burden on parameter semantics. The baseline of 4 applies because no parameters need clarification.

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 clear verb-plus-resource pattern: it returns 'the connected user's participation totals' and enumerates exactly what's included (points, credit balance, reply stats with statuses). It also scopes the data to 'work submitted through this connector,' which distinguishes it from sibling tools like check_balance or credit_history.

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

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

The description provides clear context for when to use the tool: when you need the connected user's participation totals and reply stats. It doesn't explicitly name alternatives or state exclusions, but the specificity of 'participation... submitted through this connector' implies the intended use case well enough.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description's 'Free, read-only' is consistent with them. It goes beyond the annotations by explaining what each suggestion contains (engagement counts, draft reply in the user's voice) and defining the `kind` categories (busy/early/regular) with their practical implications. It stops short of covering volume or pagination behavior, so a 4 rather than 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?

Front-loads the core identity ('the user's growth assistant: posts... that still wait for a reply') before secondary detail. The parenthetical explanations of busy vs. early add real value but make the middle dense; each sentence still 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?

No output schema exists, so the description carries the burden of describing returns — and it does, listing the fields (author, likes, comments, kind, post, link, draft) plus the engagement object shape. Only the number of suggestions returned and any pagination limits are left unstated, a minor gap for this kind of daily-digest 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?

Zero input parameters, so there is nothing to disambiguate and the baseline is 4. The only parameter-like term mentioned, `mix`, belongs to the sibling setup_growth_assistant and is correctly attributed there rather than misrepresented as an input here.

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

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

States a specific verb+resource with precise scope: posts from the last 3 days on the user's topics that still lack a reply, each bundled with a draft reply and assistant settings. An agent can distinguish it from siblings like get_posts, edit_reply, or regenerate_replies 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?

Names the alternative explicitly and the conditions that select it: if the user wants more busy threads or more early posts, use setup_growth_assistant with `mix`; if no assistants exist, offer setup_growth_assistant. It also states the follow-on action (help edit the draft; the user posts from their own account), so the agent knows what happens next.

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

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

The description complements the readOnlyHint annotation by adding 'read-only' and 'free', and by disclosing the returned statuses and reviewer notes. It does not exhaustively describe edge cases, but for a read-only status lookup the behavioral transparency is adequate.

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 two sentences: the first front-loads the exact resource and output content, the second adds the usage context. There is no redundant boilerplate, and the most important information appears early.

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

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

The description covers the purpose, result content, read-only nature, and the recommended call flow after submit_campaign_work. Since there is no output schema, a slightly more explicit return-shape description would help, but for a low-complexity read-only tool this is largely 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?

The schema only provides a required string parameter with no description (0% coverage). The phrase 'to one campaign' indirectly clarifies that campaign_id identifies the campaign, but the description does not explicitly map the parameter or explain where the identifier comes from, so it only partially compensates for the missing schema documentation.

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 clearly identifies the resource ('connected user's submissions') and scope ('to one campaign') and enumerates exactly what the tool returns: pending / approved / rejected states plus reviewer's notes. This is enough to distinguish it from siblings like get_campaign or 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?

The description gives an explicit trigger: 'Use to report outcomes back to the user after submit_campaign_work.' This is clear and actionable, though it does not explicitly name alternatives or conditions when not to use the 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?

The readOnlyHint annotation already covers safety; description reinforces with 'Read' and adds that it is 'Free'. It does not disclose return format or pagination behavior, but these are less critical given the annotation coverage.

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?

Description is concise two-sentence summary that front-loads the object of the operation and immediately supplies workflow context. Every sentence serves a distinct purpose.

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 tool, the description plus schema is mostly usable, but with no output schema and low parameter documentation, it leaves the agent to infer details about status filtering, pagination, and exactly what the response contains. It is adequate but not complete.

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

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

Schema description coverage is only 40%, and the description adds no parameter-level detail. It implies campaign_id ('a campaign's') and posts, but limit, offset, status, and include_replies are not explained beyond the schema.

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

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

Description clearly states a read operation on 'a campaign's discovered posts with their drafted replies', making the resource and purpose unambiguous. It differentiates from siblings by naming generate_posts, review_posts, and regenerate_replies in a workflow, so an agent can immediately see this is the inspection step.

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

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

Explicit guidance says to use this after generate_posts and before review_posts/regenerate_replies. This establishes a clear place in the workflow, though it does not mention alternatives like get_research or list_campaigns when campaign context is unclear.

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 the readOnlyHint annotation, the description adds meaningful behavioral details: it is free of charge, and it reports which findings are actually applied (expanded keywords/exclusion terms always active, others dormant until enabled). This provides operational nuance that annotations alone do not convey.

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 two compact sentences with no filler. The main purpose is front-loaded, and additional behavioral nuances are efficiently appended. Every sentence contributes valuable 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?

The tool is simple (one parameter, no output schema), but the description fully explains what it returns (cached analysis), how the findings are interpreted (active vs dormant), and how to influence them (via update_campaign). It also notes the free cost, covering all needed context for an agent to decide and call it.

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 0% schema description coverage, the description carries the burden for the 'campaign_id' parameter. It mentions 'for a campaign' but does not elaborate on the ID's format, source, or relationship to other campaign tools. This is minimal compensation, though acceptable for a simple identifier.

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 clearly states the tool reads cached research ('Read the cached topic/competitor analysis for a campaign'), specifying the resource and linking it to a specific source ('from run_research'). It distinguishes itself from sibling tools like get_campaign and run_research by narrowing the scope to cached analysis 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 description implies it should be used after run_research has been called, and explicitly mentions update_campaign as the way to enable dormant findings. However, it does not explicitly name alternatives or state when not to use this tool, leaving some inference to the agent.

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 annotation: discloses the 12h exclusive-match window before a deal opens to all scouts, the exact error codes (403 not_a_scout / scout_not_approved) and the corrective action with the signup URL, and confirms the tool is free. This is unusually rich behavioral context for a read tool.

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

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

Front-loaded with audience and payload, then trigger, then behavioral caveats, then failure handling. Every sentence carries distinct information; nothing is repeated from the schema or annotations except the harmless 'read-only' confirmation.

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 full burden of describing return values and does so item by item (post, why it fits, drafted opener, status, links). Audience gating and error recovery are also covered, so an agent can call and handle this tool without further information.

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 no parameters, so there is nothing to disambiguate; the description instead enumerates what each returned deal contains, which is the useful semantic detail here. Baseline 4 applies for a zero-parameter 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 ('get scout deals') plus the exact payload: today's founder post picks with post, fit rationale, drafted opener, status and links. This is clearly distinguishable from siblings like find_open_campaigns or get_my_submissions.

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 asks what deals do you have for me?') and prescribes the response behavior (show each deal briefly, let the user pick). It does not name the natural follow-on tools such as claim_deal or release_deal, so the user is left to infer the next step.

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; 'read-only' merely repeats the annotation. The one genuinely new trait is 'Free,' which tells the agent there is no credit cost to calling it. Otherwise the description discloses nothing about freshness, pagination, or per-scout scoping.

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 the returned content front-loaded and the cost/permission note last. No filler, no restatement of the name, nothing to trim.

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 returns, and it enumerates the three main payload areas (pipeline by stage, commissions, monthly rank), which is enough for an agent to know what it will get. Minor gaps remain, such as the time window for commissions and whether the pipeline is stage-aggregated or itemized.

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

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

The tool takes zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. The description correctly implies no inputs are needed and identifies the subject as the calling scout's own data.

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

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

The description names the concrete payload — scout pipeline by stage, commissions from their deals, and monthly top-scouts rank — so an agent knows what this returns. It does not, however, distinguish itself from adjacent siblings such as get_earnings or get_scout_deals, which could cover overlapping ground. Clear resource, but no sibling differentiation.

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

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

The only usage-relevant statement is 'Free, read-only,' which signals a zero-cost, no-side-effect call but not when to choose this over get_earnings, get_scout_deals, or credit_history. There is no explicit when/when-not or alternative routing. This is a cost/permission note rather than 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 and openWorldHint=false, but the description adds meaningful behavior: it explains the mode-dependent return (recent tickets vs full conversation), hints at a return field ('has_reply:true'), and states the operation is free. It does not cover rate limits or pagination behavior, but the added context is substantive.

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 compact and front-loaded: purpose first, then mode behavior, then cost/read-only note, then usage timing. Every sentence adds distinct information with no redundancy.

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 tool with two parameters and no output schema, the description covers purpose, usage trigger, mode behavior, cost, and one return-field hint. It could say more about the full return shape, but given the schema already documents limit and no output schema exists, it is largely 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 coverage is 50%, with ticket_id having no schema description. The description compensates by explaining exactly what ticket_id does: with it returns the full conversation, without it returns recent tickets. The limit parameter is already documented in the schema (default 20, list mode), so the description reasonably focuses on the undocumented parameter.

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 ('Read') and resource ('status of issues you reported ... and ProductClank's replies'). It explicitly names the sibling tool report_issue as the source of those issues, so an agent can distinguish this read tool from the reporting tool without opening either schema.

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

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

It gives a clear usage trigger: 'Check at the start of a session if you reported something earlier.' It also distinguishes the two modes (without ticket_id vs with ticket_id) and notes the cost is free. It lacks an explicit when-not or a full list of alternatives, but the context is well-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?

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with 'Free, read-only.' More valuably, it discloses data semantics beyond the annotations: what the paused state means depending on remaining credits and how to interpret a widely-missed question. It stops short of stating pagination or permission requirements, but adds genuine behavioral context.

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 what the results contain before the interpretive notes. The metric enumeration earns its place given there is no output schema, though the closing interpretation sentences are somewhat loosely appended rather than tightly organized.

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 does so thoroughly: state (live/paused/ended), started/answered/correct/out-of-tries/second-try counts, per-question performance, and credits billed. For a single-quiz read-only 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 coverage is 100% and the sole quiz_id parameter is fully documented in the schema, including its source (create_watch_quiz / boost_post's watch_quiz.campaign_id). The description adds no additional parameter semantics, so the baseline 3 applies.

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

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

States a specific resource and scope: 'Results of one of the user's watch quizzes,' and clarifies the quiz may originate here, in the web app, or on a boost, which routes the agent relative to create_watch_quiz and boost_post. An agent can distinguish this from get_campaign_results without opening either schema.

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

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

Gives clear retrieval context and interpretive guidance ('a question most viewers miss is usually ambiguous — say so'; 'paused with credits left means the user paused it; otherwise the balance ran out'). It does not explicitly contrast with the sibling results tools (get_campaign_results, get_content_campaign_results), so it stops short of full when/when-not 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 only declare the generic safety profile; the description adds the real behavior: 10-minute TTL, single-hold constraint, named failure modes (too_many_holds, already_reserved) with the correct agent response for each, timer restart on re-call, and the fact that posting is never done on the user's behalf. The re-call/restart nuance is consistent with idempotentHint=true.

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 action and timing, then sequences usage rule, return values, failure modes, and the no-auto-post constraint. Dense but every sentence carries operational information; 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 still names the return payload (draft text and held_until), and it covers the error paths an agent must handle plus the cost ('Free'). For a one-parameter reservation tool this is complete enough to call correctly without further discovery.

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 already documents 'The draft's id from find_opportunities', so the description's mention of the same source is largely duplicative. Nothing about id format or sourcing is added beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Hold one draft from find_opportunities') plus scope: 10 minutes, connected user, one hold at a time. It is clearly distinguishable from siblings release_opportunity and submit_participation, which are named as the counterpart actions.

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 ('user has PICKED a draft and is about to post') and an explicit when-not ('not to reserve work for later'). It also routes to alternatives by name: find_opportunities to get the draft, submit_participation or release_opportunity to clear an existing hold.

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/open-world safety profile; the description adds substantial context beyond them: up-front billing, per-correct-answer quiz charging, the free-plan-then-confirmed two-step flow, the quiz-question suggestion fallback, and a partial-failure/duplicate warning. This is exactly the behavioral disclosure annotations cannot 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?

Long but front-loaded: purpose, then when-to-use, then sizing/pricing, then a numbered FLOW. Every sentence carries operational weight (pricing math, flow steps, failure handling) and nothing is redundant with the 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?

For a complex 12-parameter mutating tool with no output schema, the description covers purpose, alternatives, sizing, pricing, the confirmed-call flow, and failure recovery. An agent has everything needed to call it correctly across the multi-step sequence.

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 ranges, defaults, and credits; baseline would be 3. The description adds actionable meaning beyond the schema, notably the instruction not to cap likes_count/quiz_answers at defaults when the user asks for more, plus pricing tie-ins.

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 with precise scope: 'One call for a full TikTok push on ONE video' bundling likes + replies + quiz. It explicitly distinguishes itself from boost_post and create_watch_quiz, so an agent can tell exactly what this tool does versus its siblings.

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 trigger language ('full', 'full blown', 'complete', 'combo', or likes + replies + quiz together) and names the alternative path it replaces ('instead of calling boost_post and create_watch_quiz one by one'). When-to-use is unambiguous and the substitution condition is 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 mark the tool as read-only, and the description adds useful behavioral context: results are newest first, the list includes campaigns created outside this connector, and the tool is free to use. There is no contradiction with the readOnlyHint annotation. It does not mention pagination, but that is a minor gap for a read-only listing tool.

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

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

The description is compact and efficient: a single clear sentence defines scope and ordering, followed by a short workflow note and a one-word cost indicator. There is no redundant or filler content.

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 listing tool with no required parameters and no output schema, the description provides enough context to use it correctly: what it lists, in what order, and why. It could clarify how limit, offset, and status combine or what the response looks like, but those are inferable and largely covered by the schema's enum and default values.

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 33%, and the description does not explain limit, offset, or status. It implies unfiltered 'ALL' behavior and ordering, but leaves parameter semantics to the schema. Since coverage is low, the description needed to compensate and did not.

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

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

The description clearly states the tool lists ALL of the connected user's discovery/boost campaigns, names the ordering (newest first), and emphasizes its comprehensive scope across both the connector and ProductClank web app. It also places the tool in a workflow by saying it is used to find a campaign id before get_campaign / generate_posts / get_posts, which distinguishes it from those siblings.

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

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

The description explicitly gives a concrete use case: find a campaign id before calling get_campaign, generate_posts, or get_posts. It does not explicitly state when to avoid this tool in favor of other list-like siblings such as find_open_campaigns, but the 'ALL' scope and stated workflow make the primary usage 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 already declare readOnlyHint=true and openWorldHint=false. The description adds valuable behavioral context: it lists only spaces with content engine enabled, owned/delegated/managed by the user, and the specific return schema. This goes beyond annotations, and there is no contradiction.

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 two sentences with no wasted words. It front-loads the purpose and provides actionable guidance in a compact format. 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?

Given the tool's simplicity (no parameters, no output schema), the description covers everything needed: purpose, eligibility criteria, return fields, and usage sequencing. It tells the agent to resolve the space_id for a sibling tool and confirm with the user, which is complete for this listing 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?

The tool has zero parameters, so there is no need for the description to add parameter meaning. The input schema is empty, and schema description coverage is 100% by default. The description does not add parameter info (not needed), but it does clarify the output structure. A score of 4 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 clearly states the verb 'List', the resource 'ProductClank content spaces you can draft into', and includes specific constraints (user ownership/delegation/management, content engine turned on). It also mentions the return fields { space_id, name }, making the purpose unambiguous and distinct from sibling tools like write_content_candidates or boost_post.

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

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

The description explicitly advises to 'Call this first to resolve the space_id for write_content_candidates, and confirm the target space with the user.' This tells the agent exactly when to use this tool (as a prerequisite for write_content_candidates) and includes a user confirmation step, providing strong 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?

The description adds meaningful behavior beyond the annotations: add is capped at 12 topics, omitted keywords are auto-proposed, update with is_active:false keeps a topic but stops using it, remove deletes it, and suggest generates KB-grounded ideas distinct from existing topics. This aligns with destructiveHint=true and enriches the agent's understanding of mutation semantics.

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 packs all five actions and their semantics into one dense paragraph without significant fluff. The 'FREE.' tag is slightly extraneous, and the long semicolon-separated sentence could be more scannable, but the content is appropriately sized for the tool's complexity.

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 tool with no output schema and a destructiveHint, the description covers the operational modes, limits, pause-versus-delete distinction, and the suggest workflow well enough for an agent to select and invoke it correctly. It does not describe response shapes or mention space_id, but required parameters are already documented in the 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 high at 75%, but the description adds the missing action-to-parameter mapping: add uses topics, update uses topic_id/keywords/search_context/is_active, and remove uses topic_id. It also reveals behavior not present in the schema, such as keywords being proposed when omitted, so it meaningfully supplements the parameter definitions.

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 clearly identifies the resource being managed ('the inventory of aspects a brand talks about') and enumerates five concrete actions with distinct effects. This makes the tool's purpose unambiguous and distinguishes it from sibling tools that operate on campaigns, posts, or research.

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?

Each action is mapped to a specific use case: list reads, add appends, update edits or pauses, remove deletes, and suggest brainstorms new ideas. It even gives workflow guidance for suggest ('put them to the user, then add the keepers'). It does not explicitly state when not to use the tool or name sibling alternatives, so it falls just 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?

Beyond the sparse annotations (readOnlyHint=false, destructiveHint=false), the description discloses significant behavioral consequences: making a private campaign public, turning on per-posted-reply billing (20 credits each), and demanding confirm:true only after user agreement. It also states that future drafts remain held, which is a partial-effect nuance not implied by the annotations or schema.

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

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

The description is information-dense yet every sentence carries unique value: purpose, cost, approval-step context, parameter selection, billing warning, and scope comparison. It is front-loaded with the core action and uses clear logical flow from when to use, how to pass parameters, and what to expect. No filler or repetition.

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

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

For a tool with one required, three optional parameters and no output schema, the description covers all essential aspects: preconditions, parameter selection, side effects, billing, confirmation, and scope distinction. An agent reading this description has enough information to call the tool correctly and avoid common mistakes. The absence of an output schema is not a gap here because the description's focus is on invocation and side effects.

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 schema description coverage at 75%, the schema already explains most parameters. The description adds extra value by clarifying the either/or relationship between post_ids and all:true ('Pass the post_ids the user approved, or all:true.') and by reinforcing the conditional nature of confirm. It does not duplicate campaign_id directly, but the 'campaign created with post_visibility private' context effectively hints at its role. This is a meaningful boost above 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?

The description opens with a specific verb-resource pair: 'Release chosen posts (and their reply drafts) to the community earn feed.' This clearly states the action, the object, and the exact destination. It further differentiates itself from update_campaign by explicitly contrasting scope: 'Unlike update_campaign's visibility flip, this touches only the posts you name and leaves future drafts held.'

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

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

The description gives explicit when-to-use context: 'This is the approval step for a campaign created with post_visibility 'private' (held mode).' It also explains when not to use it and names the alternative: 'Unlike update_campaign's visibility flip...' The confirm:true requirement is tied to the user agreement step, so an agent knows the exact precondition for invocation.

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

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

Annotations already declare this is a non-destructive, idempotent write. The description goes further, disclosing the actual effect ("tunes which posts the matcher picks for this scout"), cost ("Free"), and the user-interaction requirement, which are not covered by 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 short sentences with the core action front-loaded and no filler. Slightly clipped but every sentence supplies a distinct fact (action/values, cost, effect, timing).

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, but the description covers the effect of calling it, the cost, and when to trigger it, which is sufficient for a simple two-parameter rating write. Return behavior is not described, a minor gap.

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

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

Schema coverage is 50%: dealId is documented in the schema, and rating carries an enum. The description restates the enum values ("would_send" or "would_not"), which is redundant with the schema, and adds nothing about dealId or the rating's downstream effect beyond what is already structured.

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: telling ProductClank whether a scout deal was a good pick, with the two allowed values spelled out. An agent can distinguish it from sibling get_scout_deals or claim_deal, but the description doesn't explicitly contrast with those siblings.

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?

"Ask the user when they skip or finish a deal" gives a concrete trigger condition for invoking the tool. It also labels the call as "Free," but offers no explicit alternatives among the sibling tools for adjacent actions like report_deal_progress.

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

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

The description discloses important non-obvious behaviors beyond the annotations: a cost of 5 credits per reply, refusal of already-claimed replies, and the need to confirm expenditure with the user. This exceeds what readOnlyHint and destructiveHint convey, though it could additionally clarify whether existing drafts are replaced.

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 deliver the tool's purpose, side effects, cost, eligibility constraint, and user-confirmation requirement without padding. The main action is front-loaded, and every sentence adds operational value.

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 still covers the essential behavior, cost, and refusal condition. The missing output format or return value is a minor gap because the operation's user-visible effect is clearly stated.

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 schema documents only 'post_ids' with a description; the description adds concrete meaning for 'edit_request' via examples and clarifies 'post_ids' come from 'get_posts'. 'campaign_id' remains implicit, but the overall semantics are sufficiently enriched.

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 clearly identifies the action ('redraft the replies'), the target resource ('replies of specific posts'), and the mechanism ('with an edit request'). It distinguishes itself from sibling tools like generate_posts, which is about creating posts, and review_posts, which is about reviewing rather than regenerating.

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

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

The description gives clear procedural guidance: obtain post IDs from get_posts and confirm the credit spend with the user before proceeding. It does not explicitly contrast with alternatives or state when not to use this tool, but the context is clear enough for an agent to decide.

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 a non-destructive, idempotent mutation. The description adds value beyond them: the cost is 'Free', the deal returns to the shared pool, and the effect is that another scout can claim it. It doesn't cover error cases or required permissions, keeping it short of 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 tight sentences with no waste. The core action and its semantics are front-loaded, and 'Free' efficiently conveys cost 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 one-parameter mutation with no output schema and full annotation coverage, the description supplies the missing operational context (cost, pool destination, counterparty effect). Minor gaps like failure behavior are acceptable at this complexity.

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

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

Schema description coverage is 100%, and the single dealId parameter is already documented including its source (get_scout_deals). The description adds nothing about parameters, 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?

States a specific verb (release), resource (a claimed deal), and destination (back to the shared pool). It is clearly the inverse of the sibling claim_deal, and the parenthetical clarifies what 'release' means operationally.

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 trigger: 'when the user skips a deal they claimed, so another scout can take it.' This is clear context, though it doesn't explicitly name claim_deal as the complementary action or state when NOT to use it.

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

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

Goes well beyond the annotations: it scopes the operation to the caller's own hold, explains the `released: false` case (lapsed or claimed by someone else) even though no output schema exists, and notes the tool is 'Free'. That is genuine behavioral context an agent would otherwise have to discover by trial.

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 plus a short cost note, all front-loaded with the scope restriction before the edge-case semantics. Nothing is redundant.

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

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

For a one-parameter mutation with no output schema, the definition supplies the scope limit, the failure semantics of the returned field, and the cost. An agent has everything needed to call it and interpret the result.

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's description already says 'The held draft's id'. The description confirms it must be a draft the user holds, but adds no format or syntax detail, so the schema does the heavy lifting.

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 ('Release the connected user's hold on a draft') plus the reason and consequence, so an agent can tell it apart from hold_opportunity and release_deal without opening either schema. The title is matched by a description that actually explains the operation.

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 trigger context ('a draft they decided not to post') and states the downstream effect, which implies when to reach for it. It does not name hold_opportunity as the counterpart tool, so the routing is inferred rather than explicit.

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 safety/mutation profile (readOnly=false, destructive=false, idempotent=false), so the description's additions are valuable: reporting 'sent' awards Stars (a side effect), the operation is Free, and the replyUrl must be the user's own reply rather than the founder's post. It does not address what happens if the same stage is reported twice, which matters because idempotentHint=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?

Four short sentences, front-loaded with the primary action, then the constraint on replyUrl, then stage definitions. Dense but every sentence carries information; no filler or repetition.

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

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

With no output schema, the description covers cost (Free), the reward side effect (Stars), and the stage vocabulary, which is enough to call the tool correctly. It leaves the repeat-reporting/non-idempotent behavior and error handling on an invalid replyUrl 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?

Beyond the schema's terse 'Required for 'sent'', the description adds the semantic constraint that the URL must point to the user's own reply, not the founder's post. It also assigns meaning to each enum value ('replied' = the founder answered), which the schema enum alone does not convey.

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 opening 'Move a deal forward' is a clear verb+resource, and the enumerated stage transitions ('sent', 'replied', 'call_booked', 'closed_won', 'lost') make the specific function unambiguous. It is distinguishable from read-side siblings like get_scout_deals and claim_deal, 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?

It gives conditional usage rules: replyUrl is required for the 'sent' stage, later stages are 'private pipeline steps', and the guardrail 'Only report what the user tells you happened' constrains when to call it. It stops short of naming a sibling tool to use instead.

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 cover safety hints (non-readOnly, non-idempotent), so the description carries the behavioral burden and does so well: it is free, a human is alerted and replies, the result may carry a `self_help` fix for known error codes, and the agent should tell the user in one line. This is rich context beyond 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?

Purpose and the loop-retry exclusion are front-loaded, and every sentence carries actionable content. It is dense and somewhat long, but no sentence is filler.

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

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

For a write tool with no output schema and no annotations covering behavior, the description supplies the missing return-signal (`self_help`), the reply channel, and follow-up semantics. It could say more about what a successful submission returns (e.g. ticket id), but it is close to complete.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds operational meaning by specifying that the report should include the failing tool, its error code/status, and what was tried, and that ticket_id is for adding detail to an earlier report rather than opening a new one. That is a modest lift above the already-complete schema.

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

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

The description states a specific verb+resource ('Tell the ProductClank team a tool failed...') and enumerates the exact triggering conditions (failure, nonsense result, being stuck). It is clearly distinguishable from siblings, explicitly routing the agent to get_support_status for replies.

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 explicit when-to-use (instead of retrying a failing call in a loop) and when-not-to-use (expected guards like insufficient credits, confirmation prompts, spend caps — relay those to the user). The follow-up path via ticket_id vs. opening a new report is also 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?

The description clearly discloses the destructive behavior and dry-run protection, and adds important non-obvious details not visible in annotations: the 2-credit-per-post cost and the fact that dry runs are billed too. It also warns to confirm spend with the user, which is valuable behavioral context for an agent.

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 core action and dry-run behavior, followed by cost and workflow. Every sentence contributes necessary safety or sequencing information; 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, paid tool, the description is nearly complete: it covers dry-run, deletion, cost, billing, and safe sequencing. There is no output schema, so a slightly more explicit description of the verdict output format would make it fully complete, but this is enough for safe invocation.

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 schema already describes dry_run, threshold, and critical billing behavior, so the description adds only marginal value for parameter meaning beyond that. It reinforces the dry-run workflow but does not clarify anterior-to-schema parameter values or add meaning for campaign_id.

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 ('score' and 'delete') and a clear resource ('every discovered post'). It also explains the dry_run case (kept), which makes it easy to tell apart from sibling tools like get_posts or generate_posts.

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 an explicit safe workflow: start with dry_run:true, preview verdicts, then re-run with dry_run:false, and confirm spend with the user. It does not name alternatives for hand-off to sibling tools, so it stops short of explicit when-not-to-use 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 convey readOnlyHint=false and destructiveHint=true; the description goes beyond by disclosing 'Any text change clears the old score' and the credit costs for revise/fix/humanize/review, plus that editing text is free. It clarifies that staging marks ready-to-publish but publishing happens elsewhere. No contradiction. Could be a 5, but some details like idempotency or failure effects are absent.

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 dense but every sentence earns its place: action semantics, cost, side effects, user-decision boundary, and sibling routing. It is somewhat long and list-heavy, but appropriately so given seven actions. Front-loads the core purpose and defers the sibling comparison to the end.

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 high complexity (7 actions, 6 params, no output schema), the description covers what each action does, cost/credits, side effects on scores, user decision boundary, and when to use the sibling tool. The input schema adds parameter types/enums, and the description fills the behavioral gaps. Complete enough for an agent to invoke 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 covers 67% of parameter descriptions; the description enriches the action enum with plain-language meanings (e.g., 'revise rewrites it in the brand voice per a one-click preset', 'fix makes the surgical change the reviewer's notes asked for'). It also adds which parameters apply to which actions, bridging the 33% gap. Slightly more param-level detail would push to 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 ('Act on one draft') and resource ('draft in the user's queue'). Distinguishes seven sub-actions, and explicitly points to sibling tool teach_content_voice for global reactions. Title adds context. Clear and specific.

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?

Provides explicit when-to-use guidance: 'Stage and discard are the USER's decisions — act on their say-so, never on your own judgment.' Also explicitly names the alternative tool (teach_content_voice) and the condition for using it. This is model-tier 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 indicate readOnlyHint=false and destructiveHint=false, and the description aligns with that (no destructive claims). The description adds key behavioral details beyond annotations: caching for 7 days, the need for force:true to refresh, and the deferred side effect where expanded keywords are applied to the next generate_posts run. It also clarifies that other outputs are dormant until enabled. This is transparent about what the tool does and its downstream effects.

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

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

The description is dense but well-structured. It front-loads the critical 'FREE pre-flight' label, then lists the outputs, then distinguishes automated vs. dormant results, and finally covers caching and force. While a bit long, every sentence contributes to correct invocation and expectation-setting. The structure effectively prioritizes the most important 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 research tool with no output schema, the description provides a thorough inventory of what the agent will receive (expanded keywords, phrases, influencer accounts, lists, competitors) and how to act on each category. It covers the caching mechanism, the free nature, and the interaction with other tools (generate_posts, update_campaign). This is sufficient for an agent to understand when to call the tool and what to do with the results, though it could mention prerequisites like campaign existence or error conditions.

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 schema covers force with a description but leaves campaign_id undocumented (50% coverage). The tool description compensates by explicitly mentioning 'pass force:true to refresh' for force, and it implicitly defines campaign_id as the campaign being researched ('analyzes the campaign's keywords/topic'). While campaign_id is not explicitly described, its purpose is self-evident from the context, so the description adds meaningful semantic value beyond the schema.

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

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

The description states a specific action ('analyzes the campaign's keywords/topic') and lists concrete outputs (expanded keywords, high-intent phrases, influencer accounts, relevant X lists, competitors). It explicitly distinguishes itself as a 'FREE pre-flight' research step, differentiating it from get_research (which likely retrieves stored results) and generate_posts (which applies the results). The verb and resource are unambiguous.

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

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

Strong usage guidance: it tells the agent to use this tool 'before spending credits' and explains exactly which outputs are applied automatically (expanded keywords and exclusion terms via the next generate_posts run) versus which require enabling sources via update_campaign (free). It also addresses the caching scenario and how to force a refresh. This gives clear when-to-use and when-not-to-use context.

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

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

Annotations already provide readOnlyHint=true, so the description carries a lower burden. It adds that the tool returns IDs, but does not disclose behavior like partial matching, pagination, or case sensitivity. The description is consistent with annotations and adds some workflow context.

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 waste. The first sentence states the core action and output. The second sentence provides context and a workflow hint. Every sentence is essential.

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 search tool with no output schema, the description is fairly complete. It explains the purpose, output, and why the tool is needed. It could be more explicit about matching behavior, but the combination with annotations and schema makes it adequate.

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% – both parameters have clear descriptions. The tool description only mentions 'by name' which maps to the query parameter, adding no new meaning beyond the schema. Baseline 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 'Search the user's ProductClank products by name and return their IDs' – a specific verb+resource with clear output. It distinguishes from siblings like create_product and list_content_spaces by focusing on search/lookup for campaign resolution.

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

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

The description explicitly ties this tool to campaign creation/boosting workflow: 'A product_id is required to create or boost a campaign — use this to resolve it, then confirm the match with the user.' It provides clear context for when to use, though it does not explicitly mention when not to use or name 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?

The description highlights critical unattended behavior: enabling is free but authorizes later hourly job spend at 12 credits per post discovered. It explicitly warns that costs happen outside the call and without user presence, explains the safety of the off path, and gives concrete operational limits (4 runs/day, 20 posts/run, 600 credits/day) — all material that annotations do not convey.

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?

Although fairly long, every section earns its place: the warning is front-loaded, steps are numbered, and exclusions/limits are grouped logically. The text is dense with high-value guidance and avoids unrelated filler, so its length is justified by the safety-critical nature.

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

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

The description covers the invocation flow, expected first-call outputs, user-confirmation requirements, safety thresholds, cost implications, and how to read the current schedule. Given there is no output schema, the description provides enough detail for full correct invocation without leaving a necessary 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 description goes far beyond the input schema by explaining the confirmed flag's intentional flow and the meaning of an omitted confirmed flag. It also connects posts_per_run and frequency_per_day to real costs and spending limits, and clarifies that enabled:false requires no confirmation, adding behavioral context the schema cannot express.

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

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

The description opens with a precise, action-oriented statement: 'Turn standing discovery on or off for a campaign.' It clearly names the resource and the two possible operations, and it is fully distinguishable from sibling tools like get_campaign by referencing the read operation at the end.

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

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

The description provides an explicit, step-by-step usage protocol: call with enabled:true and no confirmed flag first, show the user the projected costs, get explicit agreement, then call again with confirmed:true. It also clearly states when confirmation is never allowed and when enabled:false is safe, giving the agent clear decision rules.

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 safety (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds genuinely new behavior: no money moves on this call, preview returns exact numbers, the confirmed call yields fund_url and the deposit step, and funding is irreversible. It stops short of describing failure modes or what happens on repeated previews, but it goes well beyond the annotations.

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

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

Front-loads the two-step contract in numbered form, which is the single most important thing for correct invocation, and every sentence carries information. The opening conceptual sentence about how a bounty campaign pays creators is helpful context but slightly long, keeping it short of a 5.

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

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

There is no output schema, yet the description names the key return values for both steps (pool, platform fee, total_due, per-rank prizes, fund_url) and points to the tool that confirms funding. An agent has everything needed to drive the two-call workflow end to end.

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, but the description adds value the schema lacks: the concrete default split (1st 30% / ranks 2–5 20% / ranks 6–20 50%), the default token, and the practical advice to reduce winners for small pools. The semantics of confirmed are reinforced rather than merely repeated.

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) and resource (bounty / cash prize pool) for a content campaign, and explains the mechanism: a deposited pool paid to ranked winners. An agent can distinguish this from siblings like create_content_campaign or get_content_campaign_results without opening schemas.

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

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

Explicitly prescribes the two-step flow (preview without confirmed, then confirmed:true only after user says yes), and names the follow-up tool for checking liveness (get_content_campaign_results). It also states the condition that makes the tool useless afterwards: 'A funded pool cannot be changed.'

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

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

The description adds meaningful behavioral detail beyond the annotations: structured fields are FREE, brand_doc costs 5 credits, topics are appended with a 12-per-call cap, keywords are auto-proposed when omitted, and nothing is published. These are non-obvious side effects and constraints that an agent needs to know before invoking the tool.

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

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

The description is dense but every sentence carries useful information, from billing to workflow to side effects. It is appropriately sized for an 11-parameter tool, though the long prose paragraph could be better structured with bullets or explicit sequencing. It is front-loaded with purpose and cost, which helps an agent scan it quickly.

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 tool of this complexity, the description covers the workflow, required inputs, billing, topic behavior, and the fact that nothing is published. With no output schema, a brief note about what the call returns or how to verify success would strengthen it, but the provided description is already sufficient for an agent to invoke it correctly in most cases.

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?

Even though schema description coverage is 100%, the description adds crucial semantic guidance: first-time setup requires at least voice and platforms, space_id/new_space are mutually exclusive routes, topics are appended, and brand_doc should only be passed when the user provides a written template. This materially improves parameter understanding beyond the raw schema.

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

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

The description opens with a specific action: 'Turn the content engine on for a brand from an onboarding conversation, or update its settings later.' This clearly identifies the resource (a brand's content space) and the operation (set up or update), and it does not merely restate the tool name. The title and description together distinguish it from sibling tools like generate_posts or manage_content_topics.

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

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

The description gives a concrete workflow: collect answers first via the setup prompt, read them back for confirmation, then call once. It also specifies when to use space_id vs new_space and when to pass brand_doc. However, it does not explicitly name alternatives or state when not to use this tool versus a sibling, so it stops 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?

Adds substantial context beyond the annotations: the setup is free with no credits, the paid subscription ($9/mo or $99/yr) unlocks the daily run and morning email, the card step happens in the user's browser, and the user (not the tool) posts the replies. 'Calling again updates the assistant in place' corroborates idempotentHint=true rather than contradicting it. It does not confirm destructiveHint=false explicitly, but nothing implies data loss, so the addition is largely net-positive.

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 purpose and scope, then prerequisites, then billing/flow. The pricing and card-step detail is longer than a minimal description, but it is genuinely needed because the user must consent to a subscription; sentences are dense and none are pure 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 write tool with no output schema, the description covers the full picture: what gets created, what the daily run produces, who posts the replies, cost and where payment happens, required pre-call agreements, and update-on-recall semantics. An agent has everything needed to call it correctly and to brief the user.

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 still adds value by tying parameters to a drafting workflow ('draft these from what you know about them and confirm', 'one or two sentences about who they are', 'a few rules for how their replies should read'), which explains what content to put in about/voice/topics rather than just their types.

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 (set up a personal growth assistant) and immediately scopes it as personal brand growth for the USER, explicitly 'not a product campaign', which cleanly separates it from siblings like create_campaign and create_content_campaign. The core loop (daily finds up to 5 posts on ONE network, drafts replies in the user's voice, user posts them) is spelled out.

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

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

Gives an explicit pre-call checklist: agree with the user on 2-4 topics and their search phrases, 1-2 sentences about who they are, and reply-reading rules — and says to draft these from existing knowledge and confirm. It also states when-not (not a product campaign) and what re-calling does (updates the assistant in place), covering both invocation and re-invocation.

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

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

The description adds substantial behavioral detail beyond the annotations: submissions land as PENDING, review and reward occur on approval, X URLs must be author-verified, duplicate URLs are rejected, and media must already be publicly hosted. This level of transparency is strong and non-redundant.

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 dense but well organized. It front-loads the core action and proof options, then adds constraints and post-submission behavior. Each sentence. The detail is meaningful, not 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 write operation with no output schema, this description covers the essential gaps: expected input formats, URL restrictions, verification rules, submission state, and how to check status afterward. It gives an agent enough to call the tool correctly and explain to users what happens next.

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 high at 75%, but the description enriches the parameters further—it explains that any one proof is enough, clarifies media URL requirements, mentions the 500-character limit for descriptions, and states author verification for X posts. This is useful beyond what the schema already captures.

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 clearly states the verb-resource pair: 'Submit the user's work for a campaign' and enumerates three acceptable proof types. It is specific and actionable, but it doesn't explicitly distinguish itself from the similarly named sibling tool 'submit_participation', so it loses one point for sibling differentiation.

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

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

The description gives clear context: the three proof channels, the hosting prerequisite, and the explicit routing to get_my_submissions afterward. It doesn't fully state when-not to use this tool or how it compares to submit_participation, but it gives enough usage context to select the right behavior.

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 that submitting ends the hold, that points/credits are awarded, that rejected submissions accrue strikes (3 = blocked), how verification works per platform (X author-verified live at submit; others post-hoc), and what the failure message says when a handle is missing. No contradiction with readOnlyHint=false / 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?

Action and prerequisite are front-loaded, and every clause carries information. The nested parenthetical about quote-post verification is dense and slightly hard to parse, but nothing is redundant.

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

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

Covers the full lifecycle an agent needs: hold → submit → hold released, award/credit outcome, and rejection consequences. Since there is no output schema, it could say more about what a successful response returns, but the decision-relevant context is essentially 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 coverage is 100%, so baseline is 3, but the description adds real meaning: reply_id provenance (find_opportunities) and the non-obvious semantics of reply_url for quote posts, including that a plain tweet or a quote of something else is rejected. It stops short of format details beyond the schema's uri format.

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 (submit the URL of what the user posted) and ties it to the opportunity workflow via reply_id from find_opportunities. It also scopes supported platforms (X, Reddit, YouTube, LinkedIn) and the quote-post variant, which distinguishes it from sibling write tools like submit_campaign_work or publish_posts.

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

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

Explicit prerequisites and ordering: get reply_id from find_opportunities and hold it first with hold_opportunity — submitting ends the hold. It also gives a negative rule (only submit replies the user actually posted) and a precise disambiguation for quote opportunities (pass the user's own quote post URL, not the original).

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, so the description need not re-disclose that. It adds valuable context: FREE, no credits charged, returns draft and affordability (1000 credits), and the required follow-up workflow. No contradiction with 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?

The description is a bit long but every sentence serves a purpose: scoping, cost, output, workflow, and prerequisites. It is front-loaded with the 'preview, free, nothing created' key facts. Slightly dense but well-structured.

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 tool's complexity (7 params, no output schema, safety-critical workflow), the description covers everything an agent needs: what it returns, the credit threshold, the explicit-consent and next-step requirement, and the prerequisite product_id. Nothing essential 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 covers all 7 parameters at 100%, so baseline is 3. The description adds meaning beyond the schema by telling how to fill campaign_message ('from what you know about the product') and that product_id must come from search_products. This extra guidance raises it above 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?

Clearly states it previews a campaign before launch, returns a draft and affordability check, and explicitly says it does not launch. Distinguished from sibling create_content_campaign by the 'BEFORE launching' and 'never launch' emphasis.

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 instructs to call create_content_campaign after getting an explicit yes, and never launch off the preview alone. Also specifies that product_id must come from search_products and how to write campaign_message.

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 behavior beyond the annotations: 40-credit cost, charged only on success, no charge on failure, and the explicit 'Creates nothing' guarantee that aligns with destructiveHint=false. This explains the pricing/side-effect profile (which is why readOnlyHint is false) far beyond what the annotation block 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?

Five dense sentences with no filler, and the purpose is front-loaded before cost and routing details. It is packed with distinct ideas (cost, workflow, fallback) which makes it slightly heavy, but nothing is redundant.

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

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

For a single-parameter tool with no output schema, the description covers what comes back (questions plus answers plus evidence), the cost model, the downstream handoff, and the failure behavior. An agent can call this correctly and know exactly what to do with the result.

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?

Only one parameter and schema description coverage is 100%, so the schema already documents video_url as a TikTok URL. The description implies the input is a TikTok but adds no format, validation, or constraint detail beyond the schema — the baseline 3 for full schema coverage 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?

Names a specific verb+resource+method: an AI watching a TikTok (frames + captions) to suggest counting questions with answers and evidence. It also explicitly delimits scope with 'high confidence only' and 'Creates nothing', which separates it cleanly from create_watch_quiz 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 routing: show every question WITH its evidence to the user, pass only confirmed ones to create_watch_quiz or boost_post's watch_quiz. It also names the fallback path on failure ('ask the user for questions instead'), so both the happy path and the failure path are 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?

Annotations only declare readOnly=false and destructive=false, but the description adds substantive behavior: durable rule creation, default immediate application, pending behavior with apply:false, the 1-credit cost, and the required follow-up ('Tell the user in one line what was learned'). This goes well beyond the annotation flags.

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 well-structured and front-loaded with the core purpose, followed by cost, usage contrast, parameter guidance, and response instruction. Every sentence contributes, though the example list could be slightly tighter.

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, but the description covers purpose, usage, parameter semantics, default behavior, and the expected user-facing response. It is complete enough for correct invocation, with only minor non-essential details (e.g., exact response shape, space_id clarification) omitted.

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% (space_id undocumented). The description adds rationale for draft_id ('so the rule is grounded in an example'), clarifies apply:false with 'pending in the web Settings', and gives concrete examples for feedback. This adds real meaning beyond the schema entries.

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 ('Teach') with a clear resource ('the engine', i.e., the brand's voice KB) and explicit examples of what counts as feedback. It also distinguishes itself from sibling revise_content_draft, so an agent can tell them apart immediately.

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 ('when feedback should STICK') and when-not-to-use ('use revise_content_draft when it is about one draft only'), plus additional parameter-level guidance for draft_id and apply:false. No inference is required.

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 tell the agent this is a non-destructive write; the description adds the cost profile ('free — nothing here spends credits'), the merge-not-replace semantics of keywords, the confirm requirement for visibility:public, the platform_locked precondition, and the crucial timing fact that changes apply to the NEXT generate_posts run without re-scoring existing posts. That is exactly the kind of behavioral context annotations cannot 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?

The single dense paragraph is front-loaded with the key constraint and wastes little content, but it is a long backtick-heavy run-on with no grouping or separators, which hurts scannability for a 16-parameter tool. The information is valuable; the structure is not.

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 mutation tool with no output schema, the description covers cost, side effects, confirmations, server-side rejections, timing of effects, and the platform lock. Nothing an agent needs to call this correctly 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 94% schema coverage the schema already documents most parameters, so much of the description is reinforcing that. It still adds real meaning the schema lacks — that sources stay dormant until enabled, that relevance gate behavior differs between new and existing campaigns, and why platform cannot be changed later. Not fully additive, but well above the 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?

'Adjust a live campaign without recreating it' gives a specific verb and resource plus the scope constraint that distinguishes it from create_campaign and get_campaign. An agent immediately knows this mutates an existing campaign rather than creating or reading one.

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 routes the agent conditionally throughout: 'offer it when the user will post the replies themselves', 'only do it when the user has said yes' for visibility, and it explicitly names the alternative for platform changes ('a second campaign is the answer') and for reading current lists (get_campaign). When-to-use, when-not-to, and sibling alternatives are all present.

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