campaignstack

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

Annotations already indicate this is a non-read-only, non-idempotent operation. The description adds valuable behavioral context beyond those annotations: it applies text 'through the same caps and version snapshots as a manual edit' and fails on stale targets. This gives the agent a concrete model of side effects without contradicting the annotations.

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

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

Two sentences carry a complete behavioral contract: what the tool does, how it behaves relative to a manual edit, and the key failure condition with remediation. Every clause earns its place and the most important verb is front-loaded.

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

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

The tool has no output schema, but it is an action rather than a query, so return-value documentation is less critical. The description covers the action, the mutation semantics, and the failure mode. It could be slightly more explicit about the success response, but the essential context for correct invocation is present.

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

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

Schema description coverage is 100%, and the checkupId parameter is already well documented as coming from campaignstack_get_draft_checkup. The description adds no additional parameter-level meaning, so the baseline of 3 applies.

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

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

States a specific verb ('Accept') and resource ('pending draft checkup'), and further explains the action by saying it applies proposed text to a target. It distinguishes itself from sibling tools like reject_draft_checkup and run_draft_checkup by describing the commit-like behavior.

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 clearly indicates when to use the tool: when a draft checkup is pending and should be accepted. It also provides an important exclusion cue by stating it 'fails when the targeted text changed since the checkup ran' and instructs to 'run a new checkup in that case,' which effectively steers an agent away from this tool under stale conditions.

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 the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds genuine value beyond them: it details the idempotent skip behavior ('leads already in the list are skipped') and discloses the return payload (counts of newly added and already-present leads). This is useful behavioral context a schema cannot convey, and there is no contradiction with the annotations.

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

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

Five sentences, each earning its place: purpose, idempotency behavior, parameter requirements, return value, and prerequisite tool routing. The core purpose is front-loaded in the first sentence and there is no filler or redundancy.

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

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

Strong completeness for a two-parameter mutation: the safety profile is covered by annotations, the return format is disclosed because no output schema exists, and prerequisite lookup tools are explicitly named despite a very large sibling set. The main remaining gap is the meaning of the leadSource enum values ('global' vs 'private') and error behavior for non-existent lists.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter meaning. It does restate the leadRef structure and the leadSource default ('global'), and it routes the agent to tools that produce valid IDs, which is helpful. However, it does not explain the semantic difference between 'global' and 'private' lead sources or what leadListId refers to beyond its name, leaving a real gap.

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

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

States a specific verb ('Add') and resource ('leads to an existing lead list'), making the operation unambiguous. The qualifier 'existing' implicitly distinguishes it from list-creation tools like campaignstack_create_lead_list. However, it does not explicitly differentiate from similar add-to-target siblings such as campaignstack_add_lead_to_external_list or campaignstack_queue_leads.

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

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

Gives clear workflow context by naming the exact prerequisite tools: campaignstack_list_lead_lists for lead list IDs and campaignstack_search_leads for lead IDs. This tells an agent how to assemble a valid call. It stops short of stating when NOT to use this tool or naming an alternative operation, so exclusions are left to inference.

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

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

Annotations carry idempotentHint=true, and the description substantiates it ('Duplicate adds to the same list are idempotent successes (status already_present)'). It adds rich provider-specific behavior beyond any annotation: clay's fire-and-forget webhook semantics, no provider lead id returned, the dedupe key riding along, the LinkedIn-URL-only qualification, the fact that no outreach is started, the free/no-credit property, and the full status enum including error examples. 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 long and dense, but the tool is genuinely complex (three providers with divergent behavior, multiple statuses, idempotency, exclusions). Every sentence earns its place and the core action is front-loaded. It could be improved with paragraph breaks, but no filler exists.

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 present, the description correctly takes on the burden of explaining return values — it enumerates all statuses (added, already_present, skipped_no_email, error) with concrete error examples. Combined with provider branching, exclusions, idempotency, and cost semantics, nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 83%, so the schema already documents most parameters, but the description genuinely adds meaning: it explains skipIfInWorkspace's effect ('skip leads that already exist anywhere in the provider workspace'), clarifies the provider parameter's behavioral branching (instantly/hubspot/clay), and implies leadId must correspond to a lead with an email via the skipped_no_email status. Minor gap: leadSource/workspaceId get no description-level treatment, but the schema covers them.

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

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

Opens with 'Add one lead to an external provider's lead list' — a specific verb, resource, and scope. It explicitly distinguishes itself from campaignstack_add_leads_to_list (own lists) and campaignstack_add_lead_to_sequence (starts outreach), so an agent can disambiguate without opening schemas.

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

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

Provides explicit routing guidance: names campaignstack_add_leads_to_list as the alternative for CampaignStack's own lists, states that campaignstack_add_lead_to_sequence is for starting outreach, and points to campaignstack_list_external_lead_lists for retrieving list ids. When-to-use and when-not-to-use are both explicit.

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

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

Beyond the annotations (idempotentHint=true, readOnlyHint=false), the description discloses rich behavior: Apollo auto-creates contacts, duplicate adds return already_present, activateSequence is best-effort, Instantly handoffs sync reply/bounce/unsubscribe state, the operation is free, and it enumerates possible statuses including specific error codes like INTEGRATION_NOT_CONNECTED and INTEGRATION_KEY_INSUFFICIENT_SCOPE. This is far more than the structured annotations provide.

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 adds value: scope, provider differences, idempotency, sequencing activation, state-sync side effects, billing, return statuses, and lookup tool references. The core purpose is front-loaded, and the supporting detail is compactly organized. Nothing feels like filler or repetition of the schema.

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

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

For a tool with no output schema and 8 parameters across two providers, the description is exceptionally complete: it explains the return status vocabulary, provider-specific requirements, error scenarios, idempotency behavior, and side effects. An agent has enough context to invoke the tool correctly and interpret the result.

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

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

Although the schema already covers 88% of parameters, the description adds significant provider-specific meaning: emailAccountId is required for Apollo and unused by Instantly, activateSequence is Apollo-only and best-effort, skipIfInWorkspace is Instantly-only, and campaignId comes from campaignstack_list_external_sequences. These semantics materially help an agent choose and fill 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?

The description opens with a specific verb and resource: 'Add one lead to an external provider's sequence', and immediately distinguishes it from sibling tools by naming the provider-parameterized nature (Apollo sequences, Instantly campaigns) and the external scope. This makes it clearly separable from similar tools like campaignstack_add_lead_to_external_list and campaignstack_add_leads_to_list.

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

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

The context is clear: this is for adding a single lead to an external sequence, with provider-specific behaviors spelled out. It also directs the agent to campaignstack_list_external_sequences for sequence IDs and campaignstack_list_external_email_accounts for Apollo mailbox IDs. However, it does not explicitly state when to prefer this tool over the closely related sibling add_lead_to_external_list, so it stops short of a full 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 indicate this is a non-read, non-idempotent, non-destructive operation. The description adds meaningful behavioral detail beyond annotations: URLs are validated and normalized, duplicates are skipped and reported, and per-URL success/error results are returned. This gives the agent useful expectations for calling the tool.

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

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

Four concise sentences, each earning its place: main action, behavior, return shape, and prerequisite lookup tips. Information is front-loaded and there is 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 mutation tool with no output schema, the description covers the action, input constraints (via schema), return format, and prerequisite lookups. It could be more explicit about what normalization entails or what error conditions look like, but it is sufficient for an agent to invoke the tool correctly.

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

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

Schema coverage is 67% (profileUrls and workspaceId are described, but exclusionId is not). The description compensates by adding behavioral semantics for profileUrls: validation, normalization, duplicate handling, and per-URL results. It also indirectly explains exclusionId by directing users to campaignstack_get_exclusions.

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 ('Add'), identifies the resource ('manual exclusion entry'), and specifies the object ('LinkedIn profile URLs'). It clearly distinguishes itself from sibling tools like campaignstack_remove_manual_exclusion_url and campaignstack_list_manual_exclusion_urls.

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 contextual guidance by pointing to campaignstack_get_exclusions for finding exclusionId values and campaignstack_list_signal_agents for finding signal agents. However, it does not explicitly contrast this tool with alternatives like set_agent_exclusions or remove_manual_exclusion_url, so it stops short of full when-to-use versus 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?

The annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond those hints, specifically that results are cached for 7 days per domain, which is important for agents deciding whether to call again or expect fresh data. It does not mention potential external network latency or failure modes, but the annotations cover the safety profile.

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

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

The description is three sentences, each earning its place: what the tool returns, the caching behavior, and when to use it. It is front-loaded with the core purpose and avoids any filler or repetition of schema 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 simple one-parameter read-only tool, the description is complete: it specifies inputs implicitly, enumerates the outputs, discloses caching behavior, and states the intended use case. The annotations cover safety and idempotence, so no critical behavioral information is missing.

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

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

Schema description coverage is 0%, and the description only implicitly refers to the URL parameter by saying 'Analyze a website' and mentioning 'per domain.' The single parameter is self-explanatory with format: uri, so the gap is less severe than with multiple parameters, but the description still does not clarify URL conventions such as whether a root domain is required or whether subpages are acceptable.

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 ('Analyze a website') and the resource, then enumerates the specific output fields such as company name, services, target market, tech stack, and positioning. This makes it distinct from sibling tools like get_company or enrich_company_info, which operate on stored or enriched records rather than extracting fresh intelligence from a website URL.

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: 'Use this to gather context about a lead's company before creating campaigns.' It does not explicitly mention when not to use it or name alternatives, so it falls just short of a 5, but the stated use case gives an agent enough guidance for typical selection.

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 goes beyond the annotations by explicitly calling this a WRITE-THROUGH, noting that it creates the creative on LinkedIn, and revealing that feature flag and budget guardrails are enforced server-side. This gives an agent useful expectations about side effects and possible failures.

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?

Each sentence earns its place: the action, the critical side effect, the workflow requirement, server-side guardrails, and the parameter lookup pointer. It is front-loaded with the most important information and avoids fluff.

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, the description covers the key return value (externalId), the prerequisite state (pending creative), and server-side constraints. It does not fully describe error cases or the complete response shape, but it is sufficient for selection and initial 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 description adds practical guidance for adCreativeId by directing the agent to list_ad_creatives. The platform and workspaceId parameters are already well described in the schema, so the 67% schema coverage is partially compensated. Still, the description does not add much semantic depth beyond what the schema already provides.

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

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

The description clearly states a specific verb ('Approve') and resource ('pending ad creative'), and goes further to explain that this is the publish step that creates the creative on LinkedIn and returns its externalId. This distinguishes it from related tools like approve_content_post and create_ad_creative by clarifying the actual side effect.

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 workflow context: generated/created creatives require this approval before anything is published, and it explicitly points to campaignstack_list_ad_creatives for finding the adCreativeId. It does not explicitly mention when not to use it versus reject_ad_creative, but the usage window is well defined.

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 annotations already establish the operation is not read-only, not destructive, and idempotent. The description adds useful behavioral context: it transitions the post out of pending_approval, auto-schedules when no exact time is given, and reports the resolved scheduledAt in the response. It does not discuss failure modes or edge cases, but the safety profile is already covered by 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 focused sentences: the main behavior, the scheduling options, and the sibling alternative. No filler, no repetition of schema details, and the most important information is front-loaded.

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

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

For a tool with one required parameter and no nested objects, the description is complete enough for an agent to call it correctly. It explains both scheduling modes and mentions the key response field. The absence of an output schema means more detail about the full response would be helpful, but the essential behavior is well covered.

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

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

Schema description coverage is 67%, and the description compensates well for the scheduledAt and autoSchedule parameters by explaining the exact-time path, the auto-scheduling path, and the 'omit scheduledAt' default. contentPostId gets no detailed semantics, but its role as the target post is clear from the surrounding text and 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 ('approves'), a specific resource ('content post'), and a clear precondition ('pending_approval'), plus its scheduling effect. It also names the directly related sibling campaignstack_reject_content_post, distinguishing approval from rejection unambiguously.

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

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

It clearly defines when to use the tool: when a content post is pending approval and the user wants to approve and schedule it. It also explicitly points to campaignstack_reject_content_post as the alternative for sending it back to draft. It does not mention exclusions like already-approved posts, so it falls just short of a 5.

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

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

Description discloses that approval triggers edge traversal for drafts and resumes withheld actions for escalated entries, including re-dispatching runner actions or releasing the draft. This adds meaningful behavioral context beyond the raw annotations, which only state readOnly=false and idempotent=false.

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

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

Four sentences all contribute: the first states the purpose, the next two detail the two modes, and the last gives a concrete discovery pointer. No filler or repetition of schema fields.

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

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

Covers the two complex execution paths fully, so an agent can predict side effects before calling. The lack of output-schema details is acceptable here since no output schema is provided and the action semantics are thoroughly specified.

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 compensates by telling the agent to use campaignstack_list_pending_reviews to find entryId, giving the key parameter actionable meaning. workspaceId remains generic, but its name is self-explanatory and common across workspace-scoped tools.

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 the verb 'Approve' and the resource 'pending review entry' with enough specificity to separate it from sibling approval tools for ad creatives and content posts. It also explains what approval means in two distinct workflow contexts, which goes beyond a generic one-liner.

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 identifies the two situations where the tool applies (draft at a review node, escalated entry at the acting node) and directs the agent to campaignstack_list_pending_reviews for entry IDs. It does not explicitly mention alternatives such as reject_review or retry_review, so exclusions are left to the agent, but the contexts are clear.

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

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

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description discloses the one-way stop, paused workflows, disabled automations, the fact that unarchiving does not restart anything, and the preservation of leads in flight and campaign history. It also explicitly warns to confirm with the user, which is critical for a destructive operation.

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

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

The description is front-loaded with the core action and immediately states the most important warning. Every sentence adds necessary operational or safety information, and there is no filler or redundancy; the explicit guidance about related tools is efficient.

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, one-way action with a single parameter and no output schema, the description covers all essential context: the irreversible nature, what gets paused/disables, what happens to leads and history, how to reverse, and how to locate campaigns. Nothing an agent needs to call this safely is missing.

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

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

The schema has 0% description coverage and only provides campaignId as a required string, so the description carries the burden. It adds practical context by telling the agent to use campaignstack_list_campaigns to find valid IDs if the campaign is not found, which helps disambiguate the parameter and offers recovery 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 and resource, 'Archive a campaign,' and then clarifies what archiving does. It also differentiates from related operations by explicitly naming unarchive and noting that no data is deleted, distinguishing it from deletion tools in the sibling set.

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 usage guidance: confirm with the user before calling, use campaignstack_unarchive_campaign to reverse, use campaignstack_list_campaigns with includeArchived to find archived campaigns, and use campaignstack_list_campaigns to find valid IDs when a campaign is not found. This clearly directs the agent to the right alternatives and gives preconditions.

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 readOnly, idempotent, and non-destructive behavior, and the description adds that this returns a 'ready-to-use LinkedIn search URL' rather than executing a search. The build-and-return framing makes the pure, side-effect-free nature clear without contradicting 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?

Three short sentences front-load the purpose, then describe inputs, output, and surrounding workflow. Every sentence adds useful information and there is 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 pure URL-builder with safe annotations, the description explains the key pipeline context: where criteria come from, what is returned, and how to use the result. It is missing minor details like whether criteria are AND/OR combined and that all parameters are optional, but the schema and sibling workflow cover much of that.

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

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

Schema description coverage is 0%, so the description carries the parameter documentation burden. It does list all six ICP field groups ('titles, industries, locations, seniorities, company sizes, and keywords'), but it adds no formatting or semantics beyond the schema's property names, such as the structure of the location objects or constraints.

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: 'Build a LinkedIn People search URL from ICP criteria', then enumerates the input fields and the output. This clearly separates it from search, import, and creation siblings like campaignstack_search_leads and campaignstack_queue_leads.

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 workflow: call campaignstack_list_icps to fetch ICP criteria, pass them here, then feed the URL to campaignstack_queue_leads. It does not explicitly state when not to use it or name alternatives, 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?

The description adds meaningful behavior beyond the annotations: it explains which lead states get cancelled, which are left to finish, and that the response reports how many remain. With destructiveHint and idempotentHint already present, this nuanced partial-cancellation behavior is exactly the extra context 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?

Three dense sentences front-load the effect, then provide the exception, then give the trigger context and lookup pointer. There is no filler or repetition of schema/annotation 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 destructive operation with no output schema, the description covers what will be cancelled, what won't, what the response indicates, when to use it, and how to find required IDs. Nothing critical is missing for an agent to decide to call it and interpret the result.

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

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

Schema description coverage is 0%, so the description must compensate. It indirectly explains nodeId by describing workflow nodes and telling the agent to use campaignstack_get_workflow to find node IDs, but it never mentions workspaceId or how to obtain it, leaving one of the two required parameters only inferable from its name.

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

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

The description opens with a specific action and resource: 'Cancel the drainable leads at a workflow node', then defines which entries are affected (WAITING, WAITING_FOR_EVENT, PENDING_REVIEW) and which are not (PROCESSING). This distinguishes the tool from workflow-update/delete and node-inspection siblings, so an agent can identify when this tool applies.

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 trigger: use it to drain a node when campaignstack_update_workflow or a node deletion fails with NODE_HAS_ACTIVE_LEADS, then retry the graph change. It also states what to expect for PROCESSING leads and points to campaignstack_get_workflow for finding node IDs, which is concrete routing guidance.

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

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

Annotations already mark it as read-only, idempotent, and non-destructive, so the bar for extra disclosure is lower. The description adds meaningful behavioral context by specifying the return payload, what counts as a conflict, and the account prerequisite/default resolution behavior. This goes beyond simply restating 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 compact and front-loaded: purpose first, return shape second, prerequisites and defaults third. Every sentence carries useful information with no redundant filler or restatement of the tool name.

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

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

Even without an output schema, the description fully explains the return value, including the shape of conflictingEvents. It also covers the prerequisite account connection and the default fallback behavior. This is sufficient for an agent to know what the tool does, what it returns, and what inputs matter.

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 has 100% parameter coverage, so the baseline is 3. The description adds value by explicitly documenting the behavior of googleAccountId when omitted and framing startTime/endTime as the requested range to check. This is helpful beyond the raw schema descriptions.

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

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

The description states a specific action — checking whether a time slot is available — with a clear resource (Google Calendar) and a defined result shape ({ available, conflictingEvents }). It distinguishes itself from sibling tools like get_free_slots by emphasizing a specific time slot rather than general free-slot discovery.

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 clearly establishes when to use it: to check a specific time range for conflicts. It also provides the critical prerequisite that a Google account must be connected and linked to the workspace, plus the default behavior when googleAccountId is omitted. It does not explicitly contrast with related alternatives like get_free_slots, though the context is strong 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?

Beyond the annotations (which only indicate non-read-only, non-idempotent, non-destructive), the description discloses the credit charge, refund-on-failure behavior, the fact that results are persisted to news events, and the corroboration requirement before storage. This gives the agent a clear model of the side effects and data flow.

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

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

Four sentences, each earning its place: the action/behavior, the cost/refund, where results go and how to read them, and when to use this instead of the scheduled sweep. The key purpose is front-loaded and there is 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 side-effecting action with no output schema, the description covers the operational essentials: what is performed, what it costs, what happens on failure, where results are stored, how to retrieve them, and when the on-demand check is appropriate. An agent has enough context to select and invoke it correctly.

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

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

Schema coverage is 50%: workspaceId has a schema description but companyId has none. The tool-level description clarifies that the operation targets 'one company' and that results land in news events, which helps map companyId to the company being checked. However, it does not explicitly explain the companyId parameter or add substantial detail beyond what the schema already provides, so it only partially compensates.

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

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

The description names a specific verb and resource: 'Run a fresh news check for one company now.' It details the workflow (week-fresh search, classification into corporate events, corroboration before storage) and explicitly distinguishes itself from the scheduled sweep and from reading results with campaignstack_list_company_news_events. This 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?

It tells the agent when to call the tool: for a company that needs checking right now. It also names the alternative (the free scheduled news sweep covering active-campaign, freshly-flagged, and watched companies), so the agent can decide between immediate paid-on-demand and free scheduled processing. This is explicit and actionable.

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

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

Beyond the annotations, it reveals that posting is subject to budget and business-hours gates, that bypassing removes all LinkedIn safety limits, and that this can lead to account flagging or restriction. It also explains automatic account selection, which is unobservable from annotations.

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

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

The action is front-loaded, and every sentence adds necessary operational or safety context. The warning is repeated for emphasis but earns its place given the risk of disabling LinkedIn protections.

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 required context, parameter variants, conditional account selection, and safety implications—all essential for a side-effecting tool with no schema and no output schema. Nothing needed to invoke it correctly is missing.

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

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

Despite an empty input schema, the description documents platform, target (profileUrl or leadId), commentText, accountId, and bypass behavior, including where to source accountId and commentText. The sole-source parameter documentation fully compensates for schema absence.

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

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

The opening sentence names a specific action and resource: commenting on a lead's most recent post with provided text. Combined with 'platform is required (currently LinkedIn)', it clearly distinguishes this from siblings like like_post, reply_to_comment, and send_message.

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 conditional usage: which target forms are accepted, when accountId must be provided, and that commentText can come from campaignstack_craft_comment. It lacks explicit exclusions or when-not-to-use guidance against sibling tools, but the context is unambiguous.

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 behavior beyond the annotations: it validates the key against the Apollo API, stores the integration, and notably reveals that a failed validation still creates an integrationId. This partial-failure behavior is valuable and not contradicted by 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?

Four sentences, each earning its place: the main action, validation behavior, return semantics, and a next-step pointer. The description is front-loaded with the core purpose and avoids redundancy.

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

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

For a simple two-parameter connector with no output schema, the description adequately explains the operation, validation outcome, partial-failure behavior, and what to do next. It provides enough information for an agent to select and invoke the tool correctly without ambiguity.

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 clarifies that apiKey is the Apollo API key and that it is validated against the Apollo API, adding meaning beyond the schema's type and minLength. The workspaceId parameter is already well-described in the schema as defaulting to the bound workspace, but the description does not add further context for it.

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

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

The description clearly states the action: connect an Apollo.io account by providing an API key, then validates and stores the integration. It is specifically distinguished from sibling connect tools like campaignstack_connect_hubspot and campaignstack_connect_instantly by naming Apollo.io explicitly.

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

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

The description gives clear context for using the tool: connect an Apollo.io account with an API key. It also provides a helpful follow-up step, 'Use campaignstack_list_apollo_sources after connecting to browse available contact lists.' However, it does not explicitly explain when not to use it or how it compares to other connection 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?

The annotations already mark the tool as mutating, non-destructive, and open-world, and the description adds substantial behavioral detail: validation via read ping and write-scope probe, integration storage, specific error codes, token non-echoing, subscription-tier ambiguity, and beta status. No contradiction with annotations exists.

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 each sentence serves a purpose: purpose, validation behavior, scope requirements, success/failure contract, error taxonomy, operational caveat, security note, and beta disclaimer. It is front-loaded with the core purpose and contains no redundant 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?

Given that this is an external integration call with no output schema, the description covers the essentials: token requirements, validation behavior, success/failure contract, error codes, optional scopes, security, and beta limitations. An agent has enough detail to call it correctly and handle the main failure modes.

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

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

Schema coverage is only 50% because apiKey lacks a schema description, but the description compensates by explaining the token format (pat-na1…/pat-eu1…), purpose, and required scopes. The optional workspaceId is already described in the schema as defaulting to the bound workspace.

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 ('Connect a HubSpot portal'), the exact input type (Private App access token), and what happens (validation and storage). It is clearly distinct from sibling connect tools like connect_apollo and connect_instantly by naming HubSpot and explaining the token workflow.

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 usage context: use it to connect a HubSpot portal, provide a Private App token, and ensure the required scopes. It does not explicitly name alternatives or say when not to use it, but the HubSpot-specific details make the intended scenario obvious.

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 reveals important behavior: the tool validates the key, stores the integration, and returns success true/false. It also discloses a non-obvious nuance—when validation fails, success is false but an integrationId is still created. This is valuable context for an agent deciding whether to retry or report an error.

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 focused sentences: what it does, how it validates, and what it returns. Every sentence adds essential information, and the most important action is front-loaded. No fluff or repetition.

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

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

For a two-parameter integration tool with no output schema, the description covers the essential behavior: validation, storage, and both success and failure return semantics. The unusual failure case is also explained, so an agent can set proper expectations when calling this 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 schema describes workspaceId but not apiKey, so description coverage is only 50%. The description adds that apiKey is used for validation, which helps, but it does not explain how to obtain the key or any additional constraints beyond the schema's minLength. This is adequate but not rich.

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 specific action: connect an Instantly.ai account using an API key and validate it against the Instantly API. It distinguishes this tool from sibling connect tools like campaignstack_connect_apollo and campaignstack_connect_hubspot by naming the exact platform.

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

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

The description makes the intended use clear: connecting an Instantly account by supplying a valid API key. It does not explicitly mention alternatives or exclusions, but the context is evident from the tool name and description, especially among other integration-connect 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond those annotations by specifying exactly what is counted ('entries awaiting human approval') and what the return value is (a total number). This is especially valuable because there is no output schema.

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

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

The description is one efficient sentence with no filler. It front-loads the action ('Count'), states the resource, and immediately clarifies the return value. Every clause earns its place.

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

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

For a simple count operation with one parameter, the description is complete: it states the scope, the subject, and the return format. Annotations cover the safety profile, so no further behavioral caveats are necessary. The absence of an output schema is adequately compensated by explicitly stating the return value.

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

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

Schema description coverage is 0%, so the description must compensate for the workspaceId parameter. The phrase 'in a workspace' does add some meaning by indicating that workspaceId scopes the count, but it does not explain where to obtain the ID or any additional constraints beyond the schema's minLength. The single self-explanatory parameter keeps this adequate but not strong.

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 ('Count'), names a precise resource ('pending workflow review actions'), and scopes it to a workspace. It also states the exact return behavior ('Returns the total number of entries awaiting human approval'), which clearly distinguishes it from sibling tools like list_pending_reviews.

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 intended use is implied by the verb and return value: call this when you need a count of pending review actions rather than a detailed list. However, there is no explicit mention of the natural alternative (campaignstack_list_pending_reviews) or any when-not-to-use guidance, so the agent must infer the distinction.

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

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

Annotations already cover read-only/idempotent/non-destructive behavior. The description adds return semantics ('Returns the total number') and the intended use, which is valuable since there is no output schema. It does not discuss what happens when workspaceId is omitted or invalid, but for a simple count operation this is a minor gap.

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

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

Two tight sentences: purpose, return value/use case, and routing to the sibling tool. No filler; the essential information is front-loaded.

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

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

For a simple count operation with strong annotations and a single self-explanatory parameter, the description covers the return value and points to the list alternative. The only notable omission is workspaceId behavior (optionality/default), which prevents a perfect 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 0% and the description does not explain the workspaceId parameter beyond repeating that the count is 'for a workspace.' It does not clarify whether workspaceId is required, what format it should take, or what happens if it is omitted. The property name is self-explanatory, but the description adds no parameter-level 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 names a specific verb and resource ('Count unread notifications for a workspace') and states the exact return value ('total number of unread notifications'). It also explicitly contrasts with campaignstack_list_notifications, so the agent can distinguish count from list operations.

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

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

It gives a clear use case ('useful for badge counts') and an explicit alternative: when you need to see the actual notifications, use campaignstack_list_notifications. This tells the agent when to choose this tool and when to route elsewhere.

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

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

Annotations already establish that the operation is read-only and non-destructive, so the bar is lower. The description adds useful behavioral context by noting that the comment is AI-generated and aimed at building rapport. It does not disclose, however, whether the tool returns the comment text for approval or directly submits it, which is material 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 dense sentences, with the core purpose stated first. Every sentence contributes: what it generates, what inputs it uses, and when to use it. No filler or redundant restatement of the tool name.

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 purpose, input context, and usage timing, and annotations cover safety. However, there is no output schema, and the description does not state the return value (e.g., a crafted comment string) or clarify that this tool only generates the comment and does not post it. Given the empty schema, an agent could be unsure how to call it or what to do with the result.

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

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

There are zero parameters in the schema, so the baseline is 4. The description adds conceptual meaning by naming the inputs the agent should make available: post content, lead context, and campaign context. It cannot score higher because the actual schema has no parameter fields, leaving how to pass these inputs unspecified.

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

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

The description states a specific verb and resource: 'Generate a relevant comment for a LinkedIn post.' It clearly communicates the tool's function and implies it is a drafting/generation tool rather than a posting action. It does not explicitly name or differentiate from sibling tools like campaignstack_comment_on_post or campaignstack_reply_to_comment, so it stops short of a 5.

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

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

The description gives a clear context for use: 'engaging with a lead's LinkedIn posts before or after connecting.' This tells the agent when the tool is appropriate. It lacks explicit when-not-to-use guidance or mentions of alternatives, such as using comment_on_post when the intent is to publish the comment.

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

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

Annotations only mark non-readOnly/non-idempotent/non-destructive, which is relatively uninformative. The description adds real behavioral detail: it compares agent messages with stored history, stores new messages as a side effect, and runs AI crafting plus lead-intent detection. This goes well beyond what the annotations 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?

Four tightly packed sentences with no filler; the main purpose and primary differentiator are front-loaded, and the sibling routing is stated at the end. Every sentence adds 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 no-parameter tool with no output schema, it covers the workflow, side effects, intent detection, and where to use it. The one gap is that the return value (crafted reply and/or intent classification) is implied rather than explicitly 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 input schema has zero parameters and 100% schema coverage, so the baseline is 4. The description explains the data flow ('agent-provided messages', 'stored history') despite no schema fields, though it leaves slightly unclear how messages are supplied to a tool with an empty input schema.

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

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

The description opens with a specific verb and resource ('Generate a contextual follow-up message') and explains the underlying process. It explicitly differentiates from campaignstack_craft_message for first-contact messages, so an agent can tell them apart immediately.

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

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

Provides clear routing guidance: 'Use for any message where prior conversation exists' and explicitly directs first messages to campaignstack_craft_message. This leaves no ambiguity about when this tool is appropriate.

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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by revealing that it fetches lead profile, campaign goal, ICP, and persona data from Convex and then uses AI to craft the message. It could go further by explicitly stating that it only returns a draft and does not send the message, but this is not a contradiction and the readOnly hint mitigates the gap.

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

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

Two sentences, no filler. The main purpose is front-loaded, followed immediately by usage constraints and the alternative tool. Every sentence earns its place.

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

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

For a zero-parameter generation tool, this is largely complete: it describes the inputs it fetches, the output it produces, and when it should not be used. The only minor gaps are that it does not explicitly state how the target lead/campaign is resolved (since there are no parameters) and does not state the return format, but the readOnlyHint and 'craft a message' wording make these low-risk omissions.

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 parameter documentation burden on the description. The description still adds meaning by listing the contextual data sources (lead profile, campaign goal, ICP, persona) that shape the generated message, which helps the agent understand what information influences the output.

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 ('Generate'), a clear resource ('personalized LinkedIn first message'), and the context used ('full campaign context'). It also names the exact sibling alternative, campaignstack_craft_followup, so the tool is easy to distinguish from nearby craft tools.

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

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

Explicitly says 'Use only for first messages (no prior conversation)' and routes follow-ups to campaignstack_craft_followup. This gives the agent a clear decision rule for when to select this tool versus its sibling.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond annotations: it fetches lead profile, campaign goal, ICP, and persona data from Convex, and uses AI to generate the note. It also clarifies the tool only generates text rather than sending the connection request, which is valuable.

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, front-loads the key purpose and character limit, and devotes its second sentence to routing the agent to the correct sibling. Every sentence earns its place without unnecessary detail.

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

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

For a zero-parameter generation tool, the description explains what it produces, the data sources it uses, the length limit, and when to use it vs. an alternative. It could be slightly clearer about how the target lead/campaign is selected given no explicit parameters, but overall it is sufficient 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?

The tool has zero parameters, so the schema carries no burden. The description adds meaning by explaining that the tool automatically draws on lead profile, campaign goal, ICP, and persona data from Convex, effectively clarifying how input context is resolved despite the empty parameter list.

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 the specific action ('Generate'), the resource ('personalized LinkedIn connection note'), and the explicit constraint ('max 300 characters'). It also differentiates from nearby siblings by naming the alternative use case for first messages via campaignstack_craft_message.

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 'Use for connection requests' and gives the when-not-to-use condition: 'For first messages after connecting, use campaignstack_craft_message.' This provides clear exclusions and routes to the correct sibling, leaving no inference needed.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description discloses that the campaign is created on LinkedIn immediately, that an externalId is returned, that spend ceilings and the linkedin_ads feature flag are enforced server-side and cannot be bypassed, and that the new campaign starts with no creatives. This is substantive side-effect context that annotations alone do not provide, with 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?

Four sentences front-load the core action, then layer behavioral caveats, money-object semantics, and sibling routing in a logical order. Each sentence earns its place, though the server-side enforcement sentence is slightly wordier than the rest.

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

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

For a complex 13-parameter tool with nested money objects, four enums, and no output schema, the description covers the essential invocation facts: side effect, return value, budget shape, server-side constraints, and post-creation state. It does not clarify whether a budget or schedule is required for a valid campaign, and it omits any cost implications of the live write-through, but an agent can confidently invoke the tool using the two required params listed in the schema.

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

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

With 62% schema coverage, most parameters are already documented in the schema; the description adds value by consolidating that dailyBudget, totalBudget, and unitCost all share the same money-object shape, which is most helpful for unitCost, whose schema entry only calls it a bid amount. It also reinforces the adAccountId lookup path. Semantics for name, format, objective, and bidStrategy are left to their enums, and the description does not compensate for those gaps.

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

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

The opening sentence 'Create an ad campaign' states a specific verb and resource, and the description immediately disambiguates it from the closely related campaignstack_create_ad_creative by noting the new campaign has no creatives yet and directing the agent to add them separately. The write-through nature and the returned externalId further pin down exactly what this tool does.

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

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

The description gives explicit prerequisite and follow-up routing: it names campaignstack_list_ad_accounts for finding adAccountId and campaignstack_create_ad_creative for adding creatives, which is actionable guidance. It does not, however, state when not to use this tool or contrast it with siblings like campaignstack_generate_ad_campaign or campaignstack_update_ad_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 only mark the tool as non-read-only, non-idempotent, and non-destructive. The description adds crucial behavioral detail: the creative lands as pending_approval, is NOT published, and nothing reaches LinkedIn until approved. It also discloses required permission context (human or ads:write caller) and names the returned identifiers. This goes well beyond the 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?

Three focused sentences with no filler. The most important fact — that the creative is not published until approved — is front-loaded, and the return values are stated clearly. 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?

The description covers the output (adCreativeId and assetId) and the approval workflow, which is essential since there is no output schema. However, it does not clarify that only adCampaignId and name are required, nor what `name` should represent. It also doesn't mention content length limits or whether at least one content field is needed. Slightly incomplete for a 7-parameter creation 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 only 29%, so the description needs to compensate. It adds meaning to headline, bodyText, and callToAction by describing them as text creative fields, and implies adCampaignId is the target campaign. However, the required `name` parameter is not explained, and the description lists content fields as if core while the schema marks them optional, creating mild ambiguity.

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 what the tool does: create a text creative (headline, body text, call to action) for an ad campaign. It distinguishes itself from sibling tools like campaignstack_approve_ad_creative by emphasizing the pending_approval lifecycle, and from campaignstack_create_ad_campaign by focusing on creative content rather than campaign setup.

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 contextual guidance: it is the creation step, and approval is explicitly routed to campaignstack_approve_ad_creative. This implies post-creation workflow. It stops short of explicit when-not-to-use or alternative tool comparisons, but the context is strong enough for an agent to understand the intended flow.

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

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

Goes well beyond the annotations: discloses the side effect that Google sends invite emails automatically when attendeeEmails is provided (sendUpdates=all), states the account prerequisite, explains the default account selection behavior, and documents the return shape { eventId, htmlLink }. Annotations only carry the read/write/destructive/idempotent bits; this description delivers the operational behavior an agent needs to predict consequences.

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

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

Three dense sentences that front-load the core purpose, then cover side effects, prerequisites, default behavior, and return value in logical order. Each sentence earns its place; the only minor redundancy is that the sendUpdates=all detail also appears in the attendeeEmails schema description.

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 an 8-parameter tool with no output schema, the description covers prerequisites, side effects, default parameter behavior, and the return format. Remaining gaps are minor (no explicit error behavior when no Google account is linked, and no explicit routing to sibling calendar tools), but annotations and full schema coverage already carry much of the burden.

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 every parameter already has a description, so the baseline is 3. The description mostly echoes the schema's account-selection and invite-email notes rather than adding substantially new parameter meaning; the only marginal addition is naming the sendUpdates=all mechanism explicitly.

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 the specific verb 'Create' plus an explicit resource ('Google Calendar event') and the optional attendee invitation behavior. The create-vs-update-vs-delete vs-check availability distinction among sibling calendar tools is immediately clear without opening any other tool definition.

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

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

Provides clear context for when it applies: requires a connected Google account linked to the workspace, and defaults to the first such account when googleAccountId is omitted. However, it does not explicitly name sibling alternatives (e.g., check_calendar_availability for availability checks, update_calendar_event for modifications), leaving when-not-to-use guidance implicit.

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

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

Annotations already indicate this is a mutating, non-idempotent, non-destructive operation. The description adds useful context beyond that: the tool returns the new campaign ID and title, and the created campaign is 'ready for configuration.' This helps the agent understand the immediate post-condition of the call. 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 short and front-loaded, but it is somewhat redundant: 'Create a new campaign in a workspace' and 'Creates a new campaign ready for configuration' essentially repeat the same creation fact. The return-value sentence is useful, but the third sentence could be merged or removed without losing much meaning.

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

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

This is a minimal viable definition for a creation tool. It states the return value and the campaign's initial state, and the schema covers workspace defaults. However, it lacks guidance on what 'goal' should contain, when to use this versus the many sibling creation tools, and any required prerequisites for creating a campaign. These are notable gaps, though the core call is still inferable.

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 25%, with only workspaceId having a schema description. The description mentions 'workspace' and returns 'title,' but does not explain the meaning or acceptable values of the required 'goal' parameter, nor does it clarify the optional 'description' beyond its obvious name. The low schema coverage places a burden on the description to compensate, and it largely fails to do so.

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 ('Create'), a clear resource ('a new campaign'), and the scope ('in a workspace'). It also distinguishes itself from mutation tools like update_campaign by emphasizing creation, and from create_ad_campaign by focusing on the general campaign object. The return value of ID and title further clarifies its 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 explains what the tool does but provides no guidance on when to choose it over alternatives such as create_ad_campaign, update_campaign, or archive_campaign. There are no explicit conditions, prerequisites, or 'use this when...' instructions. The intended usage must be inferred entirely from the tool name and basic description.

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 meaningful behavior beyond the annotations: first-run snapshot, weekly re-read/diff, emitted company_employee_joined signal, idempotency, and per-workspace caps. It does not detail permission requirements or failure modes, but the annotations already cover safety traits like readOnly and destructive hints.

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

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

Two dense sentences carry all key information: purpose, mechanics, cadence, side effect, idempotency, cap, and sibling distinction. Nothing is wasted and the core action is front-loaded.

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

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

For a two-parameter creation tool with no output schema, the description covers the essential operational details: what the watch does, when it runs, what it emits, and its limits. It could mention how to list, pause, or remove the watch, but those are covered by sibling tools and do not block 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?

Schema description coverage is 0%, so the description must compensate. It references 'company' and 'workspace' enough to imply what companyId and workspaceId mean, but it does not explicitly define the format, source, or validation of these IDs. The parameter names are self-explanatory, but the description could be more direct.

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

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

The description states a specific verb and resource: 'Watch a company for NEW employees' and explains the signal it emits. It also explicitly distinguishes itself from campaignstack_create_signal_watch, so an agent can tell these sibling tools apart.

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

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

It clearly explains the intended use case (tracking new employees at a company) and names the closest alternative, campaignstack_create_signal_watch, with the deciding condition: company-level vs person-level watching. The lifecycle (first snapshot then weekly diffs) also clarifies when ongoing behavior kicks in.

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 annotations already signal a non-read-only, non-idempotent, non-destructive operation, so the description adds value by disclosing automatic deduplication by normalized LinkedIn URL and workspace scoping. It also clarifies that the watch is created to monitor, implying ongoing observation. It could specify what happens when a duplicate URL is supplied, but there is no contradiction with the annotations.

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

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

Three sentences with no filler: the purpose is front-loaded, the deduplication behavior is stated second, and the discovery pointer to list_competitor_watches closes it. Every sentence carries 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?

Despite lacking an output schema, the description covers the essential semantics: what is created, the monitoring target, workspace scoping, deduplication, and how to see existing watches. It does not describe the return shape, but create operations typically return the created watch and the list tool is provided as a fallback. Given the annotations and parameter descriptions, this is sufficient 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?

The schema already documents accountIds and workspaceId well, and entityType has an enum. The description adds meaning by framing profileUrl as a LinkedIn company page or influencer profile and by explaining URL normalization dedupe behavior. The name parameter remains minimal, but the parameter name is straightforward and the description compensates reasonably for the 40% schema 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 opens with a specific verb and resource: 'Creates a new competitor watch to monitor a LinkedIn company page or influencer profile.' This precisely identifies the object and target, and the LinkedIn-monitoring focus distinguishes it from other watch-creation siblings. 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 gives clear context for when the tool is appropriate: creating a competitor watch for a LinkedIn company or influencer. It also directs the agent to campaignstack_list_competitor_watches to inspect existing watches. It does not explicitly contrast with create_signal_watch or create_search_watch, but the resource type is distinct enough that the guidance is clear.

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

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

Beyond the generic annotations, the description discloses crucial behavioral details: no backfill, only one watcher allowed per LinkedIn account across workspaces, the agent is created paused, and the workflow includes AI-crafted DM, human review, send, and follow-up rounds. These are exactly the non-obvious behaviors an agent needs to set correct 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?

Every sentence earns its place: purpose, behavior, constraint, paused state, activation path, advanced alternative, and ID lookup are all packed into a compact, front-loaded description. There is no filler or repetition of schema/annotation 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 creation tool with only two simple parameters and no output schema, the description is remarkably complete. It covers what is created, how it behaves, its lifecycle state, uniqueness constraint, activation requirement, and a preferred alternative. The only minor omission is workspaceId semantics, which does not meaningfully undermine an agent's ability to call the 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 schema has zero property descriptions, and the description compensates only partially. It explains how to find linkedinAccountId (use campaignstack_list_accounts), but it never explains workspaceId, its optional role, or how workspace scoping interacts with the one-watcher-per-account rule. The parameter names are fairly self-explanatory, but the description does not fully carry the semantic burden.

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 clear verb and resource: 'Create a connection-watch signal agent for a LinkedIn account.' It then defines exactly what the agent does (monitors newly accepted connections, routes them into a welcome workflow) and differentiates the tool from siblings like campaignstack_set_account_watcher and generic signal-agent creators.

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

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

The description gives explicit usage context: the agent starts paused, must be resumed via campaignstack_resume_signal_agent, and account IDs can be found via campaignstack_list_accounts. It also names an advanced alternative (campaignstack_set_account_watcher) and states when it is preferred, which makes tool selection unambiguous.

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

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

Annotations only mark non-read-only/non-idempotent/non-destructive, so the description adds real value by clarifying that the post is created as a draft, returns the new post ID, and infers postType from media. This goes beyond the structured hints; it could additionally disclose scheduling side effects, but those are covered by parameter descriptions.

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 with the primary action and return value, then moves to inference rules and tags. Every sentence carries information that helps an agent call the tool correctly, with no filler or repetition.

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

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

For a 9-parameter create operation with no output schema, the description covers the key behavioral nuances, return value, and retrieval route. The remaining gaps (specific meaning of body/authorAccountId, scheduling workflow) are minor because the parameter names and schema descriptions make them inferable.

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 low (33%), so the description must compensate. It does add useful semantics for postType (auto-inference rules from media) and tags (system vs freeform tags), but it leaves required parameters like body and authorAccountId unexplained and repeats little beyond the schema for the other parameters.

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 first sentence names a specific verb ('creates'), resource ('draft content post'), and platform ('LinkedIn account'), and the description explicitly differentiates from retrieval via campaignstack_get_content_post. This is enough for an agent to know exactly what operation this tool performs.

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 states the core use case and directs the agent to campaignstack_get_content_post for retrieving the full post, but it does not give exclusion criteria against close siblings such as schedule_content_post, update_content_post, or submit_content_for_approval. Some usage context is implied by 'draft' and the scheduling parameters, but the when-not guidance is left to inference.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, covering the safety profile. The description adds that a new ICP is created and made available for later scoring, but it does not disclose return values or duplicate-creation behavior—modest gaps given existing 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?

The description is four short, logically ordered sentences: what the tool does, the criteria it accepts, the recommended follow-up action, and how to obtain a required value. Every sentence earns its place, with no filler or unnecessary repetition.

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

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

For a 6-parameter creation tool with no output schema, the description covers all parameters at a useful summary level and names the follow-up scoring tool. It omits edge details such as whether at least one criterion is required or what the response looks like, but an agent has enough context to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description carries the burden. It enumerates the five optional criteria parameters and connects campaignId to the campaign concept, even telling the agent how to source valid campaignId values. It does not define value conventions for individual criteria, but the parameter names are largely self-explanatory.

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

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

The description clearly states the verb ('Create') and resource ('new ICP (Ideal Customer Profile)') and lists the concrete target dimensions: titles, industries, seniorities, company sizes, and keywords. It is distinguishable from get/list tools, though it does not explicitly contrast with the sibling create_persona or update_icp tools.

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

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

The description gives explicit workflow guidance: after creating the ICP, use campaignstack_trigger_icp_scoring to score leads against it, and use campaignstack_list_campaigns to find valid campaignId values. It does not spell out when-not-to-use or name alternatives like create_persona, but the sequencing context is concrete and useful.

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 a non-read-only, non-idempotent mutation, and the description adds that it creates a new static list and can optionally add leads. However, it does not disclose uniqueness, response shape, or failure behavior, though the annotations lower the bar.

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, action-first, with no filler. Each sentence adds distinct value: the core action, optional lead addition, and prerequisite ID lookups.

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 is complete enough for selecting and invoking the tool: it covers the required campaign scope, optional leadRefs, and ID sourcing. It could mention the response/return value or point to add_leads_to_list for existing lists, but these are not blockers.

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 compensates by explaining leadRefs structure (leadSource default 'global' and leadId) and how to obtain campaign and lead IDs. It slightly overstates leadSource as 'needs' when the schema makes it optional with a default, so it is not perfect.

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 and resource: 'Create a new static lead list in a campaign.' The word 'static' also distinguishes it from the sibling campaignstack_create_query_lead_list, so the agent can identify the correct tool immediately.

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

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

It provides clear context for when to use the tool (creating a new static list) and gives concrete lookup guidance: use campaignstack_list_campaigns for valid campaign IDs and campaignstack_search_leads for lead IDs. It does not explicitly contrast with add_leads_to_list or create_query_lead_list, but 'new' and 'static' make the primary use condition 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 annotations already indicate this is a non-read-only, non-idempotent, non-destructive mutation. The description's 'Create a new persona' aligns with that and adds no dangerous side-effect information. It does not disclose duplicate behavior, authorization needs, or downstream effects, but the annotation coverage partially mitigates this.

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

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

Three short sentences with no filler: the action is stated first, the concept is clarified second, and the prerequisite lookup is given third. 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?

The description is sufficient for an agent to understand what to create, which campaign context is required, and how to obtain the campaign ID. There is no output schema and the return value is not described, but for a straightforward create operation this is a minor gap rather than a blocking one.

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 50% schema description coverage, the description adds some meaning by explaining that personas have pain points, goals, and objections, and by pointing to campaignstack_list_campaigns for campaignId. However, it does not explain the name or description parameters, and it mostly restates what the schema already describes for the array fields.

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 ('Create') and resource ('a new persona in a campaign'), and adds conceptual context about personas representing buyer archetypes. However, it does not explicitly differentiate this from sibling tools like create_icp or update_persona, so it stops short of full 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 instruction to use campaignstack_list_campaigns to find campaign IDs provides a concrete prerequisite and helps the agent gather the required campaignId. There are no explicit when-not-to-use conditions or alternative tool mentions, but the context 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 already indicate this is a mutating, non-idempotent operation (readOnlyHint=false, idempotentHint=false). The description adds useful domain context, especially that 'the order field controls phase sequencing,' but it does not disclose potential side effects, failure modes, or whether creation requires an existing campaign beyond supplying an ID.

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 with no filler. It front-loads the core purpose, then explains phase organization and the key order-field behavior, and ends with a practical lookup tip. 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?

The description provides enough orientation for a straightforward create operation: what a phase is, that order matters, and how to obtain campaign IDs. It lacks guidance on what happens after creation, how objectives map to the phase structure, or how ordering interacts with existing phases, though the schema and mutation annotations cover some of this burden.

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 17%, so the description needs to compensate. It explains the purpose of the order field and points to campaignstack_list_campaigns for campaignId. However, it does not add meaning for objectives, name, or description beyond their obvious names, and phaseType is only covered by 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 and resource: 'Create a new campaign phase (roadmap milestone).' It also clarifies that phases organize a campaign into sequential steps with objectives. It does not explicitly differentiate itself from siblings like update_phase or list_phases, but the 'create' and 'new' language makes the intent clear.

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 when to use the tool—when creating a new phase for a campaign—and provides one useful related instruction: use campaignstack_list_campaigns to find campaign IDs. However, it does not state when not to use this tool or compare it with alternatives such as update_phase or create_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?

The description discloses the key behavioral trait that query lists resolve members dynamically from included/excluded lists and filter rules, which goes beyond the annotations. The readOnlyHint=false already signals mutation, and the description adds useful nuance about how the list behaves.

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, no filler. The primary purpose is front-loaded, and the follow-up sentence provides actionable lookup context. Every clause 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 complex nested query schema and the absence of both an output schema and any field descriptions, the description leaves substantial gaps. An agent still lacks enough information to correctly construct the query.filter, query.logic, and query.excludedLeadIds fields. The ID lookup pointers help but do not complete the picture.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that campaignId and include/exclude leadListIds can be discovered via list tools, but it says nothing about the query.logic enum, the filter array structure, or excludedLeadIds. This is insufficient for a nested query object with undocumented fields.

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 specific operation: creating a dynamic query-type lead list within a campaign. It distinguishes this from the static create_lead_list sibling by emphasizing the 'query-type' nature and how members are resolved dynamically.

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 provides concrete lookup guidance: use campaignstack_list_campaigns for campaign IDs and campaignstack_list_lead_lists for include/exclude refs. However, it does not explicitly contrast this tool with the static create_lead_list or update_lead_list, so the when-not-to-use guidance is only implicit.

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

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

Annotations are all false and offer essentially no safety profile, so the description carries the full burden — and it delivers richly. It discloses the ~6-hour polling cadence, the past-24h relevance-sorted scope, the workspace-level uniqueness constraint, the fact that a conflicting watch is created but starts disabled, and the automatic ownership transfer on archival. This is exactly the kind of non-obvious runtime behavior an agent needs and could never infer from the schema or annotations.

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

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

The description is longer than average but information-dense, with zero filler. It is logically structured: what the tool does, how the watch operates mechanically, the uniqueness constraint, the conflict edge case, and the pre-flight lookups. It is front-loaded with the core purpose, though the dense single paragraph without breaks is slightly harder to parse than it could be.

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 this much behavioral complexity — background scheduling, uniqueness semantics, disabled states, ownership transfer — the description covers the operational landscape impressively. The only notable gap is return value: with no output schema present, an agent is left uncertain whether the call returns a watch ID, a status, or the lead-feed behavior confirmation.

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

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

Schema coverage is 67%: topicId and accountIds are documented in the schema, but campaignId has no schema description. The main description compensates by establishing campaignId's role as the target campaign receiving extracted leads, and it adds conceptual meaning to topicId (a keyword monitored on LinkedIn content search, relevance-sorted) that the schema's terse "ID of the topic to watch" lacks.

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

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

The opening sentence states a specific verb and resource — "Set up a LinkedIn search watch that automatically discovers new leads for a campaign" — then precisely defines what a search watch is (monitors a topic keyword on LinkedIn content search, extracts post authors, feeds them as leads). This clearly differentiates it from sibling tools like create_competitor_watch, create_company_employee_watch, and create_signal_watch, which are all different watch types.

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

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

The description gives explicit pre-flight workflow guidance: it names campaignstack_list_search_topics for checking already-watched topics and campaignstack_get_campaign_topics for topics on the target campaign, and explains the one-watch-per-topic constraint and the disabled-start fallback. It does not explicitly state when to choose this tool over the other watch-creating siblings, but the precise definition of what a search watch is makes the selection criteria reasonably inferable.

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 goes beyond the annotations by disclosing that creation also 'Auto-generates a template workflow and lead list' and by clarifying the distinct roles of accountIds ('observe the feed') and actAccountIds ('act on signals'). This is valuable side-effect context that annotations alone do not provide. It does not fully explain the implications of responseMode auto_send, but the main behavioral surprises are surfaced.

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

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

The description is front-loaded with the core purpose and then adds necessary detail about target variants and account roles. Every sentence contributes meaning; the examples are verbose but justified by the complex polymorphic target schema. It could be slightly trimmed, but it remains efficient and well organized.

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

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

This is a complex creation tool with 11 parameters, nested objects, no output schema, and no parameter descriptions in the schema. The description covers the target structure and core account semantics well, but leaves required fields like type, targetName, and responseMode unexplained. The responseMode enum (auto_send vs review_first) is especially important for understanding autonomous behavior and should have been described. The auto-generated workflow/lead list side effect is mentioned but not elaborated on.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the target object's three shapes with concrete examples, and it clarifies accountIds vs actAccountIds. However, several required parameters — type, targetName, responseMode, and optional but important ones like silenceHours, publicReplyConfig, and followUpDelaysHours — are not given any semantic explanation beyond their names and enum values.

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 new signal agent', and specifies exactly what it monitors (LinkedIn profile, company feed, group, or post) plus the side effects (auto-generates template workflow and lead list). It distinguishes this from sibling watch/agent creation tools by describing a broader automation agent rather than a simple watch, and the target variants clarify scope.

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 usage context: when you want to create a signal agent that watches LinkedIn sources and acts on engagements. It also tells the user to call campaignstack_list_accounts to find account IDs. However, it does not explicitly contrast with similar siblings like campaignstack_create_signal_watch, campaignstack_create_connection_watch_agent, or campaignstack_create_competitor_watch, so an agent gets no 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?

The description significantly expands on the annotations by disclosing the daily refresh cadence, alert channels, monitored fields, idempotent return behavior, and the per-workspace cap on active watches. No contradiction with annotations exists.

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, front-loaded with the core behavior, and every sentence adds value: monitoring behavior, idempotence, cap, and prerequisite tools. No filler or redundancy.

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

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

The description covers the purpose, monitoring behavior, idempotence, cap, and discovery workflow, which is strong for a tool without an output schema. The main omission is leadSource semantics and perhaps explicit cleanup/removal guidance, so it falls just short of fully complete.

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

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

Schema description coverage is 0%, and the description does not explain the leadSource parameter at all. While leadId and workspaceId are inferable from context, leadSource values ('global'/'private') remain undefined, leaving a real gap for correct invocation.

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

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

The description states a specific verb and resource: watch a lead for profile signal changes. It explains exactly what happens (daily refresh, alerts on title, company, seniority, headline, location), which distinguishes it from related watch/agent tools.

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

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

The description provides clear workflow context by pointing to campaignstack_search_leads for finding lead IDs and campaignstack_list_signal_watches for current watches. It does not explicitly compare to alternative watch tools, but the usage context 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?

The annotations (all false hints) carry little information, so the description carries the burden — and it delivers: it discloses the success return shape ({ workflowId, nodeCount }), the default behavior when sourceConfig is omitted (campaign_pool with icpScoreMin 50), and the capability boundary around signal-intake graphs. It doesn't cover post-create execution side effects, but the key behavioral traits are surfaced.

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?

Six sentences, each earning its place: purpose, graph definition, prerequisite routing, return value, default behavior, and limitation. The core purpose is front-loaded in the first sentence, and there is no filler or repetition of schema 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?

The tool is complex (nested graph object, provider configs, no output schema), yet the description covers the prerequisite discovery step, return shape, defaults, and exclusions. The only meaningful gap is whether a created workflow begins executing immediately or requires a separate trigger — a behavioral detail an agent would want — but overall this is a well-rounded definition for a complex create operation.

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

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

Schema description coverage is 80%, so the baseline is 3, but the description adds genuine value beyond it: concrete node type examples (linkedin:profile_view, linkedin:connection_request, flow:wait) that the schema doesn't enumerate, plus the practical consequence of omitting sourceConfig. These details help an agent construct a valid graph and decide whether to pass sourceConfig at all.

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 verb+resource ('Create a new workflow from a graph you author') and immediately defines what a graph is — automation nodes plus directed edges. This distinguishes the tool from its workflow siblings (get_workflow, update_workflow, delete_workflow, trigger_workflow, list_workflows) without needing to inspect any of them.

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 prerequisite, 'Use campaignstack_get_workflow_node_types first to discover valid node types, their configHint shapes, and the required graph format,' which routes the agent to the correct discovery tool. It also states a clear when-not boundary ('Signal-intake graphs... are not supported by this tool'), though it doesn't name the alternative tool for that unsupported case.

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

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

The annotations only declare readOnly=false, idempotent=false, and destructive=false, so the description carries the burden of behavioral context. It does this well by explaining that accept is transactional, mirrors manual edits, fails on conflicting changes, and that reject applies no changes. This is meaningful behavioral detail 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 compact and front-loaded, with the core action stated in the first sentence and the critical failure/no-op behavior in the second. Every sentence provides necessary context without filler or repetition.

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

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

For a mutation tool with only two required parameters and no output schema, the description is mostly complete: it explains what accept and reject do, how acceptance behaves transactionally, and what to do if it fails. The only minor gap is that it does not describe the response or result of a successful decision, but that is not essential given the tool's straightforward nature.

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 proposalId and workspaceId, while decision is an undocumented enum. The description clarifies that 'accept' applies all changes and 'reject' applies nothing, which adds meaning to the decision parameter. With 67% schema coverage, the description partially compensates, though it does not add much about workspaceId or return behavior.

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 ('Accept or reject') and the resource ('pending playbook proposal'), and it distinguishes accept from reject. It also sets expectations around the proposal lifecycle, which separates it from related proposal-creation and reversion tools.

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

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

The description conveys when to use the tool: when a playbook proposal is pending and a decision must be made. It also instructs the user to propose again if acceptance fails due to stale text. However, it does not explicitly mention sibling alternatives or state conditions where another tool should be used instead.

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

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

Beyond the annotations (destructiveHint=true, readOnly=false, idempotent true), the description discloses important behavior: cancellation notifications are sent by default, a connected Google account is required, the fallback account selection behavior, and the success return value. This gives an agent a clear model of side effects and prerequisites.

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 with the core action, then adds defaults, prerequisites, and the return value in logical order. Each sentence earns its place and there is 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 calendar operation, the description covers the required prerequisites, the default notification side effect, account fallback, and the success response. No output schema exists, so stating the return shape is important and is included. The annotations already convey destructive/read-only/idempotent traits, so nothing material is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mostly restates what the schema already says about sendNotifications and googleAccountId defaults rather than adding new parameter-level meaning. It adds useful non-parameter context (account requirement and return value) but not additional semantics for the parameters themselves.

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: 'Delete (cancel) a Google Calendar event.' This unambiguously identifies the operation and its target, and the parenthetical clarifies terminology. It is clearly distinguished from the sibling tools create_calendar_event and update_calendar_event by virtue of the delete/cancel semantics.

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: it specifies the prerequisite of a connected/linked Google account, the default account selection when googleAccountId is omitted, and the default notification behavior. It does not explicitly name alternatives or state when not to use it, but the delete/cancel framing makes the primary use case evident.

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 say destructiveHint=true, but the description goes further by naming every data class destroyed and stating 'This action is irreversible.' This is exactly the context agents need beyond the flag.

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 high-stakes warning is front-loaded, the cascade list is dense but purposeful, and all three sentences contribute distinct guidance (action, irreversibility, alternatives). No filler.

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

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

With one self-explanatory parameter and destructive annotations already present, the description covers operation scope, irreversibility, and both failure and alternative routes. Nothing needed 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's single campaignId parameter has no description, but the tool name and cascade language make its meaning clear. The fallback guidance to list_campaigns for valid IDs adds semantic value about the expected value domain.

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 the operation with a specific verb ('PERMANENTLY delete') and resource ('a campaign'), then enumerates the exact cascade scope. Clearly distinct from archive_campaign and other campaign tools.

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

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

Explicitly tells when to use archive_campaign instead ('to preserve data') and how to recover from a bad campaignId via list_campaigns. This is textbook routing between siblings.

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

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

Annotations already carry the destructive profile (destructiveHint=true), so the bar is lower. The description adds value beyond that by specifying what gets destroyed — the watch plus its associated automations — and by clarifying permanence ('This action is irreversible'), which is more specific than a generic destructive flag.

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

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

Three short sentences, each earning its place: core action plus side effect, irreversibility warning, and alternative routing. The core behavior is front-loaded with zero 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 one-parameter destructive tool with annotations already covering the safety profile, the description covers purpose, side effects, permanence, and the key alternative. It is missing only minor details such as behavior on a nonexistent watchId or the expected response, which are not critical for a simple delete.

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

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

Schema description coverage is 0%, so the description must compensate. Although watchId is not explicitly documented, 'Deletes a competitor watch' makes the parameter's semantic role unambiguous: watchId identifies which competitor watch to delete. For a single, trivially inferable string parameter this is sufficient compensation.

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

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

The description uses a specific verb and resource ('Deletes a competitor watch') and discloses the key side effect ('disables its associated automations'). It also names the sibling that does something different (pause), so an agent can distinguish delete from pause without inspecting schemas.

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

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

It explicitly routes the agent: 'Use campaignstack_pause_competitor_watch to temporarily stop monitoring instead,' establishing when-not (temporary cases) and naming the exact alternative. The contrast with the pause sibling makes the permanent-deletion use case unambiguous.

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 destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral context beyond the annotations: deletion is restricted to draft/failed posts, implying failed attempts for other statuses. It doesn't describe error behavior or side effects, but the key extra constraint is disclosed.

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

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

Two short sentences with no filler. The action is front-loaded, the precondition follows immediately, and the helper reference is placed at the end. Every sentence earns its place.

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

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

For a simple one-parameter destructive operation, this is complete. The description covers what it deletes, when deletion is valid, and how to verify before calling. No output schema exists, so not describing return values is appropriate.

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%, but the only parameter, contentPostId, is self-explanatory from its name. The description adds meaning by indicating that the ID must reference a post in draft or failed status, and it points to a getter for verification. This compensates for the sparse 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 uses a specific verb ('Deletes') and resource ('a content post'), and adds a precise status constraint. This clearly distinguishes it from other delete_* siblings and identifies the object of the operation.

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

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

It explicitly states when deletion is allowed (draft or failed status) and tells the agent to use campaignstack_get_content_post to check status first. This gives both a precondition and a concrete alternative/helper step.

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

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

The annotations already mark the tool as destructive and not read-only, but the description adds important context: the deletion is permanent, irreversible, and cascades to associated scoring data. This goes beyond the annotation flags and helps the agent warn users appropriately.

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 concise sentences: the first states the action and key consequence, the second gives the prerequisite lookup step. Every sentence earns its place, with no redundant 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 single-parameter destructive tool with annotations covering read-only/destructive/idempotent hints, the description is complete. It covers what is deleted, the irreversibility, the cascading data removal, and how to obtain the required ID.

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 has one parameter, icpId, with 0% description coverage. The description tells the agent to find ICP IDs via campaignstack_list_icps, which provides practical sourcing guidance, but it does not clarify expected format, examples, or any nuance about the ID beyond its name.

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 ('delete'), a clear resource ('an ICP'), and the extended scope ('its associated scoring data'). It clearly distinguishes this tool from related siblings like create_icp, update_icp, get_icp_scores, and list_icps.

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 directs the agent to use campaignstack_list_icps to find ICP IDs before deleting, which is a concrete prerequisite. It does not explicitly state when not to use this tool, but for a deletion operation the guidance is 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?

Annotations already include destructiveHint=true, so the destructive nature is known. The description adds value by stating the deletion is permanent and cannot be undone, which goes beyond the annotation's generic destructiveness signal and warns the agent about irreversibility.

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 only two sentences, with the core action front-loaded first, followed by the critical irreversibility warning and a targeted prerequisite instruction. Every clause earns its place.

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

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

For a simple single-parameter destructive tool, the description provides the necessary action, permanence warning, and a safe invocation pattern. No output schema is needed for the agent to understand that the deletion result is all-or-nothing.

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

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

Schema coverage is 0%, so the description carries the burden of explaining the personaId parameter. While it does not directly define 'personaId,' instructing the agent to confirm the ID via campaignstack_list_personas adds meaning about how to obtain a valid value before calling the tool.

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

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

The description states a specific verb and resource: 'Permanently delete a persona.' This immediately distinguishes it from create, update, get, and list persona tools, and it explicitly notes that deletion is permanent.

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 provides clear pre-use guidance: 'Use campaignstack_list_personas to confirm the persona ID before deleting.' This is practical and context-rich, though it does not enumerate explicit when-not-to-use scenarios or mention alternative deletion-related 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 declare destructiveHint=true, but the description adds a crucial behavioral detail beyond that: 'This action cannot be undone.' This clarifies irreversibility and reinforces the need for caution, providing value beyond the structured annotation.

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

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

Two short sentences carry all essential information: the action, its irreversibility, and a safety step. There is no filler, and the most important information is front-loaded.

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

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

For a one-parameter destructive action without an output schema, the description is largely complete. It explains the operation, the irreversibility, and how to safely obtain the required ID. It does not describe cascading effects on related campaign data, but this is a minor gap given the simplicity of the 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 0% and phaseId is only described as a string. The description compensates by identifying the parameter as a campaign phase ID and instructing the agent to confirm it via campaignstack_list_phases, which gives practical sourcing semantics beyond the bare schema.

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

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

The description opens with a clear verb and resource: 'Permanently delete a campaign phase.' It unambiguously distinguishes this from sibling tools like campaignstack_update_phase, campaignstack_get_phase, and campaignstack_list_phases by emphasizing permanence and deletion.

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 pre-use guidance: use campaignstack_list_phases to confirm the phase ID before deleting. This tells the agent exactly what to do before invoking the tool, though it does not explicitly cover when-not-to-use scenarios or alternative non-destructive actions.

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 destructive and idempotent behavior; the description adds valuable detail by explaining exactly what gets disabled, that it is a soft-delete, and that data is preserved for audit. This goes well beyond the 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?

Four ideas packed into three tight sentences with the main action front-loaded. There is no filler, and every sentence contributes either to identifying the behavior, its consequences, or how to obtain the required parameter.

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 operation, side effects, data preservation, and ID lookup, which is strong for a one-parameter tool. It stops short of stating whether the archive action is reversible or if a new agent must be created to restore functionality, which would be useful context for a destructive 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 schema provides no description for agentId, but the description compensates by naming the resource as a signal agent and telling the agent where to find valid IDs via campaignstack_list_signal_agents. For a single simple string parameter, this is adequate 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?

States a precise action: 'Archive (soft-delete) a signal agent.' The side effects listed (stops polling, pauses workflow, disables watched posts, clears competitor linkage) clearly distinguish it from generic delete operations and from pause/resume sibling tools.

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

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

Provides clear operational context and explicitly instructs the agent to use campaignstack_list_signal_agents to find valid agent IDs. It does not explicitly name alternatives like pause_signal_agent or state when not to use this tool, but the archiving semantics are clear enough to guide selection.

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 operation as destructive, but the description adds valuable specifics: the deletion is irreversible and cascades through workflow nodes, edges, lead-list source providers, lead progress entries, per-lead contexts, and webhook tokens. This goes well beyond the annotation and accurately discloses the full destructive footprint.

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

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

The description is three sentences with no filler. The irreversible action and cascade scope are front-loaded, followed immediately by actionable lookup guidance and the safe alternative. 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 one-parameter destructive tool with no output schema, this description is complete: it states the action, the irreversible consequences, the full cascade of affected data, how to obtain the required ID, and the non-destructive alternative. An agent has everything needed to invoke this tool correctly and avoid harmful mistakes.

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 only defines workflowId as a required string with no description, so schema description coverage is 0%. The description compensates by telling the agent to use campaignstack_list_workflows to find workflow IDs, clarifying where the parameter value comes from. It does not elaborate further on the parameter's meaning, but the parameter name and this guidance are sufficient for such a simple tool.

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

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

The description opens with a specific verb and resource: 'Permanently delete a workflow and all associated data.' It immediately distinguishes this from non-destructive workflow operations and clearly defines the scope of the deletion, making the tool's purpose unmistakable.

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 how to find the required workflow ID using campaignstack_list_workflows, and explicitly names the alternative when deletion is not intended: campaignstack_update_workflow_status. This gives clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds a detailed account of what the diagnostic report covers: lead existence, ICP score, threshold checks, dedup status, exclusions, per-provider filters, and a verdict. This goes well beyond the annotation hints and makes side-effect expectations explicit.

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 lengthy but every clause adds information: purpose, accepted inputs, report contents, and lookup helpers. It is front-loaded and avoids filler, though the list of report categories makes it denser than necessary.

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

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

For a complex diagnostic tool with no output schema, the description covers inputs, the full scope of the report, and how to obtain valid identifiers. The main gap is the mismatch between the described parameters and the empty input schema, which leaves the actual call contract ambiguous.

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 has zero properties, so the description is the only source of parameter meaning. It clearly names workflowId and the leadId-or-profileUrl choice and notes that profileUrl is a LinkedIn URL. It loses a point because it omits types for workflowId and leadId and because the described parameters are absent from the structured schema, which could confuse invocation.

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 object: 'Diagnose why a specific lead was or wasn't sourced into a workflow.' It then enumerates the report contents, making the tool's purpose unmistakable and distinguishing it from lookups like search_leads or get_lead_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?

It names the two lookup tools to call for valid workflowId and leadId values and states the accepted identifier combination. It doesn't explicitly contrast with alternative diagnostic tools, but the context of sourcing diagnosis is clear.

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

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

The description discloses several crucial behaviors beyond annotations: credits already used are not refunded, restarting warmup begins from week 1 and costs credits again, and the return value includes { success: true, previousStatus }. It also explains the informational response when no active warmup exists. This is rich, relevant behavioral context that matches the destructiveHint and idempotentHint 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 five sentences, each carrying important information: the primary action, credit/restart consequences, return shape, no-op behavior, and a pointer to the relevant sibling tool. It is front-loaded with the core purpose and avoids filler or redundant restatement of the tool name.

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

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

For a tool with no output schema and two parameters, the description fully covers what the agent needs: what the tool does, side effects, return structure, edge-case behavior, and where to look for warmup states. There is no missing operational detail that would prevent 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?

The input schema has 100% description coverage, so the schema already explains googleAccountId and workspaceId. The description adds no additional parameter-level meaning, but because the schema is fully self-documenting, 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 opens with a specific verb and resource: 'Disable email warmup for a connected Google account.' This clearly distinguishes the tool from the enable_warmup sibling and from read-only warmup list/status tools. The purpose is unambiguous and directly 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 gives clear context for using the tool, including behavior when no active warmup exists and a pointer to campaignstack_list_workspace_warmups for viewing all warmup states. It does not explicitly say 'use enable_warmup to enable instead,' but the opposite operation is implied by the tool's name and description. A minor gap is the lack of explicit exclusions, such as 'do not use if warmup is already disabled'.

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 signal destructiveHint=true; the description adds the important specific that the integration record and stored credentials are permanently deleted. This gives the agent a concrete understanding of what is destroyed beyond the bare annotation.

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, front-loaded sentences: what it does, the destructive consequence, valid providers, and a helpful pointer to the list tool. 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 simple destructive tool with a rich schema, most necessary context is present. However, the inaccurate provider list weakens completeness: an agent cannot reliably tell which providers are actually supported, and there is no mention of what happens when the provider is not connected. A clarifying note about the optional workspaceId would also help.

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 all parameters at 100%, so the baseline is 3, but the description's provider list contradicts the schema enum by omitting 'hubspot'. This can mislead an agent into thinking hubspot is invalid, and it does not clarify the optional workspaceId behavior.

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 ('Disconnect (remove)') and names the resource ('an integration') with the exact side effect: permanently deletes the integration record and stored credentials. It is clearly distinct from the connect_* and list_integrations 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?

It orients the agent by naming the valid providers and points to campaignstack_list_integrations for discovering connected integrations. It does not explicitly list when-not conditions or alternative connect tools, but the usage context is clear.

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

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

Annotations only say non-read-only and non-idempotent; the description adds crucial cost/concurrency behavior: 500 credits charged and refunded on failure, and one concurrent run per workspace. It does not disclose the return shape or what happens if a concurrent run already exists, but the disclosed side-effect profile is strong.

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

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

The core purpose is front-loaded and every clause adds useful information: process, cost, refund, concurrency, topics, and follow-up tools. It is sentence-like and dense rather than neatly structured, but there is no padding.

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

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

For a complex kickoff tool with no output schema, it covers the essential operational context—cost, refund, concurrency, optional topics, and the exact polling/scheduling tools. It stops short of stating what the tool returns (e.g., a run ID), which an agent would need to start the polling loop immediately.

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 topics including its workspace-union default; the description reinforces that topics narrow the search. However, workspaceId has no schema description and the description does not explain how it is used or defaulted, leaving half of the parameter surface undocumented.

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 action ('Start a lead magnet discovery run') and details the whole pipeline: Google search for last-7-day LinkedIn posts, comment-count fetching, magnet classification, and ranking by reachable commenters. It clearly distinguishes this tool from the numerous sibling lead-magnet tools by framing it as the run-starter, not a list/get/schedule 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?

It gives actionable routing: poll get_lead_magnet_run for progress and set_lead_magnet_schedule for weekly recurrence, plus the option to narrow via topics. It lacks explicit 'when not to use' exclusions or alternatives for starting vs sourcing lead magnets, but the main follow-up choices are covered.

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

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

Beyond the annotations, the description reveals important behavioral traits: dismissal is sticky, auto-promotion stops permanently, and the promoted relevance boost is removed. This meaningfully adds context about persistence and side effects. Annotations already cover idempotency and non-read-only nature, so the description does not need to restate those.

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

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

Two compact sentences deliver the purpose, the behavioral consequences, and the persistence caveat with no wasted words. The core action is front-loaded and every clause earns its place.

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

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

For a low-complexity tool with idempotent and non-destructive annotations, the description covers the essential selection and invocation context. The main residual gaps are the unstated workspaceId semantics and the absence of any return-value or response expectations, both minor for this simple mutation.

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 creatorId with a helpful source ('Creator ID from campaignstack_list_lead_magnet_creators'), but workspaceId has no description and the tool description adds no parameter-level meaning. With 50% schema coverage and no compensating description, parameter semantics are only partially clarified.

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 ('Dismiss a creator') and then explains the exact consequences: no more auto-promotion and no promoted relevance boost. It clearly distinguishes this from the sibling dismiss_lead_magnet_post (which targets a post, not a creator) and from promote_lead_magnet_creator by noting dismissal is sticky until promoted by hand.

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 for when to use the tool: when a creator should never auto-promote again and should stop receiving the promoted relevance boost. It also implies the undo path ('until promoted by hand'), but it does not explicitly name the alternative tool or state when not to use it, so it falls just short of a 5.

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

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

Annotations already declare idempotency and non-destructive behavior. The description adds valuable behavioral context beyond annotations: dismissal is per workspace and does not affect other workspaces discovering the same post. This helps an agent understand the cross-workspace isolation semantics without contradicting the annotations.

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

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

Two concise sentences with no filler. The primary effect is front-loaded, and the workspace scoping clarification is provided immediately after. Every sentence contributes useful 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 simple, state-changing tool with idempotency and non-destructive annotations, the description covers the essential semantics: what it does, the outcome, and the workspace scoping. It could additionally mention reversibility, but given the annotations and simple parameter set, nothing critical 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 describes junctionId as originating from campaignstack_list_lead_magnet_posts, but workspaceId has no schema description. The description's 'per workspace' statement indirectly hints at workspaceId's role, but it does not explicitly document the parameter or its optionality. At 50% schema coverage, the description provides only partial compensation.

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 ('Dismiss'), resource ('magnet candidate'), and the concrete outcome ('stops appearing in the candidate list'). It also clarifies the workspace-scoped nature, distinguishing this post-level dismissal from related tools like dismiss_lead_magnet_creator.

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

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

The description gives clear context for when to use the tool: when a magnet candidate post should be removed from the candidate list. It does not explicitly name alternatives or exclusion conditions, but the effect and scope are unambiguous enough for an agent to select it appropriately.

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 useful behavioral detail beyond the annotations: it states that body, platform, author, and media are copied, lifecycle fields are cleared, and a new post ID is returned. Since the annotations already indicate this is a mutating, non-idempotent, non-destructive operation, this is sufficient 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 concise sentences convey the operation, copied fields, cleared lifecycle fields, and return value with no filler or redundant restatement of the tool name.

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

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

For a single-parameter operation with no output schema, this description is complete: it explains what happens, what is inherited, what is reset, and what the caller receives. No critical operational detail appears to be 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 input schema has no description for contentPostId and schema coverage is 0%, so the description must compensate. The phrase 'existing content post' makes it clear that contentPostId refers to the post being duplicated, but the parameter itself is never explicitly documented or connected to a source.

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 ('Duplicates') and identifies the exact resource ('an existing content post') and outcome ('as a new draft'). It also names what is copied and what is cleared, making its role clear against siblings like create_content_post or update_content_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 intended use is strongly implied: use this when you need a clean draft copy of an existing content post. However, the description does not explicitly state when to choose this over create_content_post or update_content_post, nor does it offer any exclusions or alternative 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?

Beyond the annotations, which only indicate the operation is not read-only and not idempotent, the description adds meaningful behavioral detail: the original content is preserved for audit trail, the lead advances via the 'approved' edge, and escalated actions are resumed with the edited text. This gives the agent a clearer picture of side effects and workflow impact.

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, with the core action in the first sentence and supporting workflow details in the next two sentences. Every sentence provides useful information, and there is no filler or repeated schema 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?

The description explains the two workflow scenarios and their outcomes well, which is helpful for tool selection. However, it lacks parameter-level guidance and does not describe the expected shape of updatedContent or what the caller should provide beyond 'edited text,' leaving some invocation ambiguity.

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

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It only hints at updatedContent through 'your edited text' and never explains the meaning or expected structure of entryId, workspaceId, or updatedContent. The agent is left to infer parameter roles from names 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 clearly states the tool's function: edit AI-generated content and approve a review entry. It implicitly differentiates itself from related siblings like approve_review by adding the editing step, but it does not explicitly name any sibling or contrast itself with them.

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 contextual usage by describing two distinct workflow states: a draft parked at a review node and an escalated entry parked at the acting node. It does not explicitly say when not to use the tool or name alternative tools such as approve_review or reject_review, but the context is clearly scoped.

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

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

Annotations already establish this as a non-read-only, non-destructive, idempotent operation. The description adds useful behavioral context: the scheduled slot is preserved, in-flight sends are refused with DRAFT_ALREADY_DISPATCHING, and non-scheduled entries are refused with DRAFT_NOT_SCHEDULED. No contradiction with annotations appears.

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 with no filler: the first states the operation and key preservation guarantee, the second explains content shape, and the third covers failure modes and source of valid entries. Everything earns its place.

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

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

For a mutation tool, the description covers what is edited, what is preserved, when it fails, and how to locate eligible entries. There is no output schema, but the success path is simple enough not to require a return-value breakdown. A minor gap is not describing a success response or exact contents of updatedContent beyond { messageText }.

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 has zero descriptions, but the description clarifies the otherwise-opaque updatedContent object by referencing the content shape of campaignstack_edit_and_approve_review and giving { messageText } as an example. entryId and workspaceId are left to be inferred from their names and the description context, which is acceptable though not explicit.

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: 'Change the text of an approved message that is still waiting at its send node, keeping its scheduled slot.' It clearly distinguishes this from related tools like campaignstack_edit_and_approve_review by emphasizing the scheduled, already-approved state and slot preservation.

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

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

Gives explicit applicability conditions: the message must be approved and still waiting at its send node. It names the content-shape reference tool, describes when the tool refuses (in-flight send or non-scheduled entry), and points to where valid entries come from, giving an agent clear routing information.

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