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?

It discloses that the tool creates a campaign, spends credits, auto-detects platform from URL, and lists platform-specific capabilities such as YouTube replies plus likes and reposts only on X/Farcaster. It also instructs the agent to confirm the action and credit cost with the user, adding meaningful behavior 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?

The description is dense but every sentence contributes: core purpose, credit costs, platform constraints, product_id decision, and required user confirmation. It is well-organized and front-loaded with the primary outcome before moving to details.

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 four parameters, platform-specific behavior, credit costs, and a potentially costly side effect, this description is exceptionally complete. It tells the agent exactly what will happen, what each action costs, where it is supported, how to tailor replies, and what to confirm with the user before invoking.

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 enriches the parameters: it quantifies credits per action, clarifies platform support per action_type, and explains the optional product_id behavior with product-linked tailoring versus generic tweet-first language. This is meaningful added guidance.

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-plus-resource statement: 'Rally the ProductClank community to engage with a specific social post.' It clearly distinguishes boosting a post from broader campaign tools by detailing exact engagement types and credit costs.

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 operational context: when to use the tool, supported platforms, action_type choices, and when to include or omit product_id. It does not explicitly contrast this tool with sibling alternatives like create_campaign or create_content_campaign, but the use case is clearly implied.

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 readOnlyHint=true and openWorldHint=false, and the description adds useful behavioral context by specifying what is returned (balance and plan) and what the numbers mean in practice. It does not contradict the annotations, and it provides enough behavioral context for a zero-parameter read-only 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 concise and front-loaded, stating the core purpose first and then giving the practical use case. The pricing details are directly relevant to the decision to call the tool and take up only one sentence.

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

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

With no parameters and a read-only annotation, the description is fully self-sufficient for an agent to know when and why to call it. It also supplies the important context of campaign credit costs, which helps the agent interpret the return value even without an output schema.

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

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

There are zero parameters, and the schema description coverage is 100%, so parameter documentation is not a concern. The description helps by clarifying that the balance is for the connected user, which is the only relevant contextual semantic.

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

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

The description uses a specific verb ('Return') and identifies the exact resource (the connected user's ProductClank credit balance and plan), making the tool's function clear. It is distinct from the sibling credit_history by focusing on the current balance/plan snapshot, but it does not explicitly call out that difference.

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 tells the agent to use this tool before launching a campaign and gives concrete credit thresholds for different campaign types. It provides a clear trigger condition but does not mention when not to use it or point to alternatives such as credit_history.

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 far beyond the annotations: it costs 10 credits, topic research auto-runs in the background, public mode posts to the earn feed and bills extra, and private mode is reversible. It also warns not to silently guess keywords when web access is unavailable. None of this contradicts the readOnlyHint=false / destructiveHint=false 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 long but the tool is complex and the length is mostly earned by operational instructions, cost warnings, and decision defaults. It is front-loaded with the core definition and workflow. Some redundancy with the schema exists (e.g., platform options and visibility semantics), but the repetition reinforces high-stakes decisions.

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 12-parameter, billed, multi-mode campaign creation tool with no output schema, this description is exceptionally complete. It covers preparation, cost model, mode selection, platform choice, background research, prerequisites, and post-creation next steps. An agent can confidently proceed to invoke the tool correctly.

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

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

Even though schema coverage is high at 92%, the description adds crucial meaning: keywords must be derived from real audience language, search_context steers discovery and relevance, platform must match where the audience actually talks, and visibility has cost/reach implications. The platform-specific targeting guidance also clarifies behavior not fully captured by the schema alone.

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

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

The description opens with a specific verb and resource: 'Create a Communiply discovery campaign' and immediately explains what it does — continuously finds relevant social posts by keyword and drafts replies mentioning the product. This clearly distinguishes it from siblings like 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?

There is extensive usage context: prerequisites (product_id via search_products/create_product), cost confirmation, defaulting to private visibility, and the recommendation to read get_research before using generate_posts. However, it does not explicitly state when to use an alternative tool such as create_content_campaign, so it lacks a true when-not/exclusion statement.

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

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

Annotations 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?

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?

The description states the operation is 'Free, read-only', matching the readOnlyHint annotation and adding an explicit guarantee. It also discloses the tool's return scope: every active public campaign plus campaigns from communities the user belongs to, with each item clarifies the difference between content and take_action campaigns. It does not cover pagination or infrequent details, but the annotations already establish a safe read operation.

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

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

The description is compact and front-loaded, giving the core behavior first: 'every active public campaign plus campaigns from the user's communities'. It then adds useful kind details and workflow guidance without waste. 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?

This is a simple, read-only listing with two optional parameters described in the schema, so the description no need extensive output details. The description covers what is returned, the kind distinction, and the recommended next step. An agent can safely call this tool and interpret the results 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?

The input schema already has 100% coverage with descriptions for 'kin d' and 'lim it', so the baseline is 3. The description does not add additional meaning about the parameters beyond the schema's info; it discusses 'kind' in terms of results rather than filtering.

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 purpose: discovering campaigns the connected user can join and earn from, including active public campaigns and community campaigns. It also defines the 'content' versus 'take_action' kind distinction. However, it does not explicitly differentiate this tool from the similarly broad siblings 'find_opportunities' 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 provides clear context for when to use this tool — the user wants campaigns they can participate in and earn from. It also gives a workflow signal by directing the agent to follow with 'get_campaign_brief'. It does not explicitly mention when not to use this tool or name alternatives like 'list_campaigns' or 'find_opportunities'.

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 set readOnlyHint=true and openWorldHint=false; the description affirms 'read-only' and adds the important requirement that the user must have the platform handle linked for attribution. It also clarifies that items are real social posts, adding context beyond the annotations. Minor gap: it does not mention any rate limits or pagination behavior, but the schema covers limits.

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

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

The description is well-structured: purpose first, then flow, then exclusion. Every sentence adds value—no fluff. It is reasonably concise for the complexity and front-loads the essential 'what' and 'read-only' 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?

For a read-only browse tool with 3 optional params and no output schema, the description covers the flow, attribution prerequisite, and what is excluded (likes/reposts). It does not describe the exact response structure, but that is not critical for a list tool. The only minor omission is lack of explicit mention of pagination defaults, though limit/offset are in 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 description coverage is 67% (limit and campaign_id have descriptions, offset does not). The description adds no parameter details, so it does not compensate for the missing offset description. Since coverage is above 50%, the baseline is 3, and the description adds zero extra parameter meaning.

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

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

The description states a specific action ('Browse unclaimed reply drafts'), the resource ('active campaigns the connected user can earn from'), and the output nature (real social post + pre-drafted reply with platform). It differentiates from siblings by explicitly noting that likes/reposts are handled elsewhere, so an agent knows exactly what this tool returns.

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 flow: pick an opportunity, post the reply, then call submit_participation with the URL. It also excludes likes/reposts by stating they are handled via screenshot in the web app. This gives explicit when-to-use and next-step guidance, and implicitly contrasts with submit_participation.

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 mark this as read-only, so the bar is lower; the description adds meaningful context by mentioning 'live stats', 'free', and the categories of data returned. It does not contradict the readOnlyHint and gives useful behavioral expectations.

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 tightly written and front-loaded with the core purpose. Every sentence adds unique information with no redundancy or 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 compensates by naming the returned content: configuration fields and live stats. It could be marginally richer on exactly what status values appear for replies, but for a one-parameter read tool it is sufficiently 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 already documents campaign_id fully as 'Campaign UUID (from list_campaigns or create_campaign)' with 100% coverage. The description adds no new parameter semantics, so the baseline of 3 is appropriate.

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

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

The description names a specific verb and resource ('Get one campaign's configuration') and lists exactly what is returned, differentiating it from list_campaigns and other campaign-related tools. It is impossible to mistake this for a list or write 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?

The description explicitly tells the agent when to call it: after generate_posts or before adjusting the campaign. It does not state formal exclusions or compare direct alternatives, but for a single-resource read tool this is clear 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 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?

Find_occasions sets readOnlyHint:true; resets is read-only and free. It further describes non-obvious behavior: externally linked instructions must be fetched and followed, and that the tool implies a downstream submission step. This is valuable behavioral context beyond what annotations already reveal. It does not contradict 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 well-sized, starts with the essence, and uses a compact list to convey many required elements. The second sentence adds contextual instruction without over-inflation, although the last sentence includes downstream steps that are not strictly performed by this 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?

Since the tool has no output schema, the description carries responsibility and adequately enumerates return value: campaign action message, sections, content types, eligibility criteria, judging, rewards, deadline, and remaining submission limit. It also warns about external instruction links, making it reasonably complete for the task of consuming the brief.

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 explains that campaign_id comes from find_open_campaigns. The description adds no extra parametric semantics such as formatting, ownership, or relationship to the user granted submission state.

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 is a full participation brief for one campaign and enumerates its contents (action message, sections, judging criteria, rewards, deadline, submissions left). This is more specific than a generic read-only campaign tool, though it does not explicitly compare itself to the sibling get_campaign, so it stops just short of full sibling distinction.

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

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

The description communicates the flow around the tool: read the brief, follow any external instructions, then work with the user and submit_campaign_work. That is a clear context, but the overall purpose describes a workflow when it should be used before submission, and unlike a direct alternative, it does not offer any differentiation from sibling campaign/brief tools. Explicit 'when not to use' guidance is also absent.

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?

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?

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?

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 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?

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 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?

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?

Beyond the annotations, the description explains the handle-connection requirement, X's live verification and other platforms' deferred verification, the failure behavior when handle is missing, and the strike penalty for rejections. This substantially clarifies the tool's side effects and risks.

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 main action and then adds relevant caveats about identity verification, failure behavior, and consequences. It is compact enough, though the last sentence contains multiple dependent clauses and concepts that could be better segmented.

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 has no output schema, the description covers prerequisites, error behavior, and reward/penalty outcomes well. It does not explicitly state the full response structure, but an agent can gather enough to predict success/failure and side effects, making it complete for a 2-param tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific meaning beyond the schema, aside from confirming reply_id’s origin and noting the URL applies across platforms. It does not significantly enrich either parameter's semantics.

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

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

This description states a specific verb and resource: 'Submit the URL of the reply the connected user posted for a claimed opportunity.' It clearly distinguishes the tool from siblings like submit_campaign_work by limiting it to posted replies and naming the platforms and the source id. The purpose is unambiguous and actionable.

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 strong contextual guidance: only submit actual posted replies, requires reply_id from find_opportunities, and warns about missing handle failure and strike penalties. It does not explicitly point to alternative tools or say when not to use them, 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 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?

Even with annotations present, the description adds significant behavioral detail: the operation is free but subsequent generate_posts runs bill normally, keywords MERGE rather than replace, setting is_active:false pauses billing, flipping visibility to public releases already-discovered drafts, and platform becomes locked after discovery. These are exactly the non-obvious behaviors an agent needs.

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. It front-loads the core purpose and cost model, then covers each nuanced parameter in one focused clause or sentence. There is no filler, repetition, or marketing language.

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 12-parameter mutation tool with no output schema and sparse annotations, the description covers the critical pitfalls: merge semantics, dormant sources, locked platform, billing effects, public visibility confirmation, list replacement semantics, and timing of changes. The schema covers the remaining parameter formats, so nothing essential is missing for correct 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?

Although schema coverage is high at 92%, the description goes well beyond the schema by explaining real operational meaning: sources stay dormant until enabled, add_keywords merges without dropping, relevance_threshold starts at 5 and should be raised when discovery is noisy, target_subreddits/target_youtube_channels replace rather than append and require reading the current list first, and visibility public requires user consent and confirm:true.

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: 'Adjust a live campaign without recreating it.' This distinguishes update_campaign from create_campaign and other siblings by framing it as in-place tuning rather than creation/recreation, and the title reinforces this.

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 context for when this tool is appropriate and when it is not: 'without recreating it', 'after that it is fixed, and a second campaign is the answer', and 'Changes apply to the NEXT generate_posts run.' This tells the agent both when to tune the existing campaign and when to escalate to a new campaign.

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 non-destructive write operation. The description adds valuable behavioral details: the tool is free, no credits charged, candidates become unreviewed drafts requiring human review, and nothing is auto-published. This goes well beyond annotations, though it could mention rate limits or error recovery behavior.

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

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

The description is a single dense paragraph of five sentences, each serving a distinct purpose. It front-loads the action and key constraints. While efficient, it could benefit from brief bullet points for scannability, but it's not overly verbose or wasteful.

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 (2 params, no output schema), the description covers purpose, usage prerequisites, behavioral traits, sibling differentiation, and limits. It does not explain error handling or response format, but for a straightforward writing tool with no output schema, this is adequate. Additional details on possible errors or state changes would raise the score.

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 dynamic baseline is 3. The description adds minimal parameter-specific context beyond the schema: only the instruction to resolve space_id via list_content_spaces. The schema already describes both parameters well, so the description does not significantly enhance parameter understanding.

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 'Draft' and the resource 'content candidates into a ProductClank content space'. It explicitly distinguishes from the sibling 'create_content_campaign' by noting this is for the user's own pipeline, not a community campaign. The purpose is specific and 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 clear context: it drafts into the user's own content space, advises resolving space_id via list_content_spaces first, and states the limit of 25 candidates. It explicitly contrasts with create_content_campaign for community campaigns. However, it does not mention when other siblings like boost_post or suggest_content_campaign would be more appropriate, slightly limiting the guidance.

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