campaignstack

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

Annotations already declare destructiveHint=true, openWorldHint=true, readOnlyHint=false, but the description adds real behavioral context: it modifies a third-party workspace and 'may make contacts available for outreach there,' plus the human-in-the-loop confirmation requirement. Auth needs and failure modes are still unstated.

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

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

Four short front-loaded sentences, with the scope first and the safety prerequisite after. 'This reaches a real person' is echoed verbatim in the confirmed param description, a minor redundancy that keeps it from a 5.

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

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

Output schema exists, so return values need no explanation, and annotations carry the safety profile (destructive, open-world, idempotent). The description supplies the missing confirmation and real-person stakes, leaving nothing essential absent for a mutation of this complexity.

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

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

Schema coverage is only 40%, so the description must compensate, and it does partially by pinning 'up to 25 leads' (the maxItems) and 'one provider list or sequence' (destination.type). But provider, destination.id, and activateSequence/skipIfInWorkspace flags are left entirely to the schema, and the confirmation text is essentially duplicated from the confirmed param.

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

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

Specific verb+resource+scope: 'Add up to 25 leads to one provider list or sequence' names exactly what the tool does and the bounded size. It is distinguishable from write-siblings like import_external_leads or export_leads_to_crm by the 'external destination' target, but no sibling is named 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?

Gives clear context and a precondition: it changes a third-party workspace and reaches a real person, so the agent must read wording back and wait for an explicit yes. It stops short of naming alternatives or exclusions (e.g., when to prefer import_external_leads), so it is not 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 cover safety (readOnly, idempotent, non-destructive), and the description adds real behavioral context beyond them: cached analyses are reused, fresh AI extraction is credit-gated, and charges hit the bound workspace. This is exactly the kind of cost/side-effect disclosure the annotations cannot express.

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

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

Three compact sentences with the scope statement front-loaded and the cost path last. The 'Renamed V2' opener is the one piece of low-value text, but overall there is little waste.

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 an output schema present, return values need no explanation, and the description covers the key operational facts an agent needs: caching, credit cost, and workspace charge attribution. Only the url parameter's invocation semantics remain unexplained, which is a minor gap for a plainly named URI field.

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 carries a thorough schema description, but url has only format:uri with no textual guidance. The description implies url is the company's own public website but adds no format or constraint detail, so it neither compensates for nor exceeds the schema.

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

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

States a specific verb+resource: a read-only analysis of a company's own public website. The 'Renamed V2' prefix is internal jargon that adds no selection value, and it does not explicitly differentiate from siblings like enrich_companies, but the core purpose is unambiguous.

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

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

It gives useful usage context — cached results are reused, fresh extraction is credit-gated, and it routes the agent to campaignstack_estimate_cost before committing. However it never states when to prefer this over sibling enrichment tools or what conditions select it.

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

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

Annotations already declare destructive=true, openWorld and non-idempotent. The description goes further, disclosing that answers are persisted to the watcher's profile for future matching questions and that the application resumes under review, credit, and account daily-limit gates — meaningful side-effect context. It still does not detail what data is destroyed or reversibility.

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

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

Three tight sentences, front-loaded with the eligible state and followed by the side effects and the confirmation rule. No filler, though the gating clause is rather dense.

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?

An output schema exists, so return values need no explanation. Combined with annotations and schema for workspaceId, the description covers persistence, resumption gates, and the confirmation requirement adequately; only applicationId lacks any documentation.

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

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

With only 50% schema coverage, the description must compensate. It clarifies that answers must be the person's verbatim input and that confirmed is required after read-back, but applicationId (required, undocumented in both) remains unexplained, 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 (send answers) and resource (application stopped at needs_answer), pinpointing the exact precondition. An agent can distinguish it from campaignstack_apply_to_job or campaignstack_get_job_applications without opening a schema.

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

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

Gives a clear condition ('Use only answers the person gave you; read every answer back first. confirmed:true is required') and the state gating eligibility (needs_answer). It does not name a sibling alternative or exclusion, but the when-to-use 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?

Annotations already declare destructive=true, idempotent=false, and openWorld=true, so the safety burden is partly carried. The description still adds real value by explaining that the tool drafts a cover letter in the person's voice and parks it for review before submitting under automatic-mode and account-safety gates, clarifying what 'apply' actually does.

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

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

Three sentences, front-loaded with the verb and scope, then the pipeline, then parameter/precondition rules. Dense but every sentence carries information; no filler or marketing 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 destructive, non-idempotent mutation with an output schema, the description covers scope, approval precondition, parameter selection, and what happens downstream. It omits failure modes and any rate/permission constraints, but the core is complete enough to invoke correctly.

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

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

Schema description coverage is 100%, so all four parameters are already documented, including the workspaceId defaulting logic and the postingId 'one live watcher' condition. The description largely restates the schema's confirmed/applicationId/postingId guidance rather than adding format or edge-case detail, making 3 the correct baseline.

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

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

States a specific verb and resource ('start an application for exactly one matched posting') and distinguishes itself from the read-side siblings like campaignstack_get_job_applications by describing the drafting/parking pipeline it kicks off. An agent can tell what this does without opening the schema.

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

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

Gives concrete selection rules: pass applicationId, or postingId only when exactly one live watcher matched, and requires explicit human approval before confirmed:true. It does not name the sibling tools to consult first (e.g. get_job_applications), but the preconditions are clear enough to route correctly.

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 destructiveHint=true annotation: it states the watcher leaves live lists, never searches or applies again, and that previous applications remain readable. That is the exact irreversibility/side-effect profile an agent needs before calling a destructive mutation.

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, no waste, front-loaded with the permanent/archival nature before the alternative and the confirmation requirement. Every sentence earns its place.

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

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

With an output schema present, return values need no explanation, and the description covers irreversibility, the reversible alternative, the confirmation gate, and the workspace resolution is handled by the schema. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 67%; workspaceId and confirmed are richly documented in the schema, and the description reinforces the confirmed semantics and its user-facing obligation. watcherId remains undocumented in both places, so it falls short of full coverage but adds real meaning for the risky parameter.

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

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

States a specific verb and resource ('Archive one job watcher permanently') and immediately contrasts with the reversible sibling (pause in campaignstack_edit_job_watcher). An agent can distinguish it from edit_job_watcher without opening either schema.

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

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

Explicitly names the alternative tool and the condition that selects it: 'Use pause in campaignstack_edit_job_watcher for temporary stops.' It also states the precondition for the destructive path (confirmed:true after naming the watcher/account back to the user).

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

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

Annotations already flag destructiveHint=true and idempotentHint=false. The description goes further by enumerating exactly which entry states are cancelled (waiting, event-waiting, pending-review) and disclosing that processing or sent work cannot be recalled and is reported separately, which is genuinely useful beyond the structured fields.

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

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

Two sentences, zero filler, and the operation type is front-loaded before the state-level detail. 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. The description supplies the cancellation scope and irreversibility caveat, leaving only minor gaps around nodeId format and permission prerequisites.

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%: workspaceId and confirmed are self-documented in the schema, and nodeId has no description at all. The description adds only the indirect hint that the node is a single unit of work; it does not explain nodeId format or how workspaceId omission behaves. Baseline 3 given the schema already carries most parameter meaning.

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

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

States a specific verb+resource combination ("cancel" on "leads" for "one workflow node") and scopes it to a single node. An agent can distinguish it from broader siblings like campaignstack_delete_workflow or campaignstack_retry_workflow_entries, though no sibling is named 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 phrase "Confirmed drain operation" implies when this is appropriate, and the note that processing/sent work cannot be recalled sets a boundary. However, it never states when to prefer this over retry_workflow_entries or delete_workflow, so usage is inferred rather than guided.

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

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

Annotations already flag destructive/openWorld/non-idempotent, and the description adds substantial context beyond that: the comment is public and stays under the owner's name, it reaches a real person, there is no draft state and nothing to recall, and sends are paced by workspace-set daily/weekly/business-hours limits that are not writable. It also pre-empts misuse of overrideOwnLimits, describing exactly what it voids and the audit-log consequence.

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

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

Front-loaded with the core action and the approval precondition, then routing to alternatives, then safety. It is longer than typical, but nearly every sentence carries routing or safety information. Minor redundancy with the schema's own overrideOwnLimits prose keeps it from a 5.

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

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

For a high-risk outbound mutation with an output schema already handling return values, the description covers prerequisites (explicit user yes), targeting, pacing constraints, the one-per-call rule, the bulk workaround, and the override consequences. An agent has everything needed to call it safely and 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 only 38%, so the description must compensate and does: it explains leadId is the supported form and profileUrl is for existing workspace contacts, that platform is required, that accountId targets a specific connected account, and what commentText must contain. Workspace-level defaults for workspaceId are handled in the schema itself. Some ambiguity remains over exact limit-enforcement interactions, hence not a 5.

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

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

States a specific verb+resource+target: 'post a comment on a lead's most recent post from a connected LinkedIn account.' It distinguishes itself from siblings by naming campaignstack_craft_message, campaignstack_submit_comment_for_review, and the bulk path (campaignstack_edit_lead_list + campaignstack_trigger_workflow), so an agent can tell it 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?

Explicit when-to-use ('when the user has approved specific comment wording'), explicit alternatives for the adjacent cases (draft with craft_message, park for review with submit_comment_for_review), explicit anti-pattern ('calling this in a loop over a list is not the supported way'), and the correct bulk alternative. Nothing 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 the safety profile (readOnly=false, destructive=false), and the description adds beyond that: it explains why the tool is non-OAuth, that secrets are validated and never echoed back, and that existing config is replaced. One mild tension exists between 'store or replace' (upsert-flavored) and idempotentHint=false, but it is not a clear safety-profile 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?

Three compact sentences, with the core action front-loaded and the caller-routing caveat placed after it. No filler, though the second sentence is information-dense enough that it borders on packing two concerns together.

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 annotations and an output schema present, the description only needs to add what structured data cannot: it covers the secret-handling behavior, the non-OAuth rationale, and the replace semantics. What remains unstated (e.g., whether replacement invalidates existing connections) is a minor gap for a 3-parameter tool.

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

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

Schema description coverage is 67% and the credentials/workspaceId fields already carry their own explanations, including the provider enum. The description only restates 'provider-nested credentials' without adding format, validation, or per-provider nuance, so the schema is doing the heavy lifting.

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

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

The description states a specific verb+resource ('Store or replace one provider integration') and immediately characterizes the input shape ('provider-nested credentials'), so an agent knows exactly what the tool does. It implicitly separates this from the OAuth-based connect flow, but does not clearly distinguish it from the sibling campaignstack_edit_workspace_integrations, leaving one ambiguity among the integration-family 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?

It gives clear context for use (non-OAuth providers whose credentials are supplied directly) and a concrete when-not-to-use path ('connected apps should direct the user to the workspace's Settings tab'). It stops short of explicitly naming an alternative tool, so it is strong context rather than full routing guidance.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds real value beyond them: it discloses that the result is a browser handoff rather than a direct connection, and it explicitly commits that OAuth secrets, cookies and passwords are never collected in chat. It stops short of saying what the handoff payload contains or what completes the 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?

Two tight sentences with the capability front-loaded and the security constraint following. No filler, no redundancy, and nothing that could be cut without losing information.

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

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

An output schema exists, so return-value details are rightly omitted, and annotations already declare the mutating/open-world nature. The description supplies the remaining agent-critical facts: the two supported platforms, the browser-handoff mechanism, and the no-credential-in-chat guarantee.

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 carries a thorough schema description covering key types and the multi-workspace error case, while platform is an undocumented enum. The description's "LinkedIn or Google" merely restates the enum values and adds nothing to workspaceId semantics, so it neither compensates for the gap nor falls below the baseline for this coverage level.

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

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

States a specific verb ("return a browser handoff") and resource ("connecting a new LinkedIn or Google account"), which is much more precise than the bare title. It scopes to NEW connections, implicitly separating it from campaignstack_get_accounts or edit_workspace_accounts, though it never names those siblings directly.

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

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

Usage is only implied: the word "new" suggests this is for onboarding an additional account rather than editing an existing one, steering the agent away from edit_workspace_accounts. There is no explicit when-to-use statement, no prerequisites, and no named alternative.

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

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

Adds real behavior beyond the annotations: sent:false is returned, sending and booking are deliberately out of scope, and schedulingAcceptance with booked:false is surfaced when a follow-up discovers a prior accepted time. That said, it does not say whether drafts persist or overwrite, nor anything about idempotency, for a tool whose annotations show a non-read-only mutation.

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 front-loaded sentences with no filler; the no-send constraint and the approval gate come first. Slightly dense with domain-specific terms (schedulingAcceptance, booked:false) that assume prior context.

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 output schema means return values need no explanation, and the safety/approval story is well covered. However, for a 16-parameter tool with 25% schema coverage, many inputs remain opaque, so an agent can understand the intent but not reliably populate all arguments.

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 25% across 16 parameters, so most inputs (leadId, template, instructions, conversationMessages, campaignId, workflowId, commentText, postContent, meetingKind, the reschedule timestamps) are explained nowhere. The description largely restates the already-documented channel and kind enums, so it does not compensate for the coverage gap.

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

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

States a specific verb and resource (draft one outbound message) and immediately bounds it (without sending anything), which cleanly separates it from siblings like campaignstack_send_message or campaignstack_comment_on_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?

Tells the agent when this applies (drafting, not sending) and what must follow (read the draft back, then call a separate send/action tool only after explicit approval). It never names the specific sibling send tool, so routing still requires a lookup, but the workflow intent is 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 (which already declare the non-read-only, non-destructive, non-idempotent, open-world profile), the description discloses return behavior (workspaceId immediately, generationId to follow via campaignstack_get_workspaces), auth constraints (user key or signed-in connection; a workspace key cannot create another), and rate/limit rules (one build at a time, free accounts capped at two workspaces). This is substantive context the annotations cannot carry.

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

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

Front-loaded with the core action and then organized by input, return, auth, and limits; nearly every sentence carries distinct information. It is dense and the account-linking sentence runs long, but the length is defensible for a tool with this many conditional behaviors.

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 four optional parameters, an output schema, and no annotations for safety beyond the hints, the description covers the remaining gaps an agent needs: which inputs are valid combinations, what happens with none, what is returned, what credentials are required, and the concurrency/quota limits.

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, but the description adds real meaning beyond the schema by explaining parameter interactions and defaults: goal becomes the campaign goal verbatim, name is derived from the company when omitted, and the website/profile URL rules determine what the workspace contains. That interplay between parameters is not fully captured by the per-field schema text.

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 ('Create a workspace and build it') and then enumerates exactly what the build produces (company context, playbook, first campaign with ICP, workflow, lead pool), which cleanly separates it from sibling mutators like edit_workspace or onboard_workspace. An agent can tell what this tool does without opening the schema.

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

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

Gives explicit when/when-not rules: pass goal only when the user stated the purpose, leave name out unless the user chose one, a website alone suffices, a profile URL requires the user's own connected LinkedIn account, and with neither URL you get a blank workspace that must be named. Alternatives and prerequisites are named rather than implied.

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

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

Annotations only give destructiveHint/openWorldHint; the description goes far beyond by disclosing pacing behavior ('can take hours' vs 'within seconds' with priority:true), that priority skips queue limits but never account-level refusals (paused/expired/risk-paused account errors out), and that confirmed:true results in a real send or submission. This is exactly the context an agent needs before an irreversible action.

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 action and the sibling alternative are front-loaded in the first sentence, and every following sentence carries distinct operational information rather than filler. It is dense and runs long, but no sentence is purely redundant with the schema or annotations.

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

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

For a destructive, open-world tool with an output schema (so return values need no explanation), the description covers both kinds, the priority escape hatch and its limits, the confirmation requirement, and the edit payload. 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?

At 63% schema coverage, the description compensates meaningfully: it spells out the edit_and_approve payload shape (updatedContent { letter?, answers?: [{ question, answer }] }) and that reject may carry a reason, neither of which is documented in the schema. It adds less for entryId/workspaceId, but the nested-object gap is covered.

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

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

Opens with a specific verb trio and the exact resource scope: 'Approve, reject, or edit-and-approve one pending review.' It also names the sibling it is not (campaignstack_edit_draft) and the condition that selects it, so an agent can route between the two without opening either schema.

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

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

Explicit alternatives and conditions: 'To save a revised draft for a person to sign off instead of deciding it, use campaignstack_edit_draft,' plus narrow routing for priority ('Use priority only when the user asked for this message to go out now') and kind-specific behavior for workflow vs job_application. When-to-use and when-not-to-use are both stated.

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

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

Annotations already establish destructiveHint=true and non-idempotency, but the description adds value beyond them: the archive-based mechanism, bounded batch edits, one result per item, and the instruction to report partial failures rather than claiming whole-batch success. The mild internal tension between 'archiving' and 'permanently deletes a root record' is a wording wrinkle, not a contradiction of 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?

Purpose is front-loaded, but the confirmation requirement is stated twice in near-identical terms ('Call this only after the user confirms the exact watches to remove' vs 'name exactly what will be deleted ... wait for an explicit yes'), which is redundant bulk for a six-sentence 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 a destructive batch delete gated by explicit confirmation, the description covers irreversibility, batch bounds, and partial-failure reporting, and an output schema exists to cover return shape. The only gap is the absence of any hint about the workspaceId parameter's multi-workspace requirement, which is left entirely to the schema.

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

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

Schema description coverage is 67%, so the schema already does most of the work, and the description never discusses watchIds or the workspaceId fallback logic. It only implies the batch nature ('Batch edits are bounded', 'one result per requested item'), and the confirmation text duplicates the 'confirmed' parameter's own schema description. Baseline 3 fits.

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

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

Specific verb plus resource ('Delete company employee watches') with the mechanism disclosed ('by archiving them so they no longer refresh'). This cleanly separates it from siblings like campaignstack_edit_company_employee_watch and campaignstack_get_company_employee_watches, so an agent can route without opening a schema.

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

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

'Call this only after the user confirms the exact watches to remove' gives a clear precondition for use. It does not, however, name the alternative to reach for when the user only wants to modify a watch rather than remove it (e.g. edit_company_employee_watch), so the when-not/alternative half of the guidance is missing.

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 idempotentHint=false, but the description adds substantial context beyond them: permanent root-record deletion, irreversibility, disabling of scheduled automations, bounded batch size, one result per requested item, and the requirement to report partial failures. This is unusually rich disclosure for a destructive tool.

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

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

Front-loads purpose, then confirmation precondition, then batch/result semantics. The confirmation instruction largely duplicates the `confirmed` schema description, which is mild redundancy, but no sentence is wasted within the description itself.

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 an output schema present, return-value formatting needn't be explained, and the description correctly focuses on preconditions and partial-failure semantics. It leaves workspace-scoping behavior to the schema, which is reasonable, though a note on multi-workspace ambiguity would have made it fully self-contained.

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%. The description implies bounded batching (max 25 watchIds) and echoes the confirmation requirement that the `confirmed` schema field already documents verbatim, but adds no syntax, ID format, or workspace-resolution guidance beyond the schema's own workspaceId text. Baseline 3 is appropriate.

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

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

States a specific verb+resource (delete competitor watches) plus a secondary effect (disable their scheduled automations), which distinguishes it from campaignstack_edit_competitor_watch and campaignstack_get_competitor_watches. An agent can identify the operation without opening the schema.

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

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

Gives an explicit precondition (call only after the user confirms the exact watches to remove) and a required confirmation protocol. It does not name the obvious alternative (edit_competitor_watch) for partial changes, so it stops short of full when-not/alternative routing.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is known. The description adds that this is permanent, irreversible, targets a 'root record' (implying cascading deletion), and requires explicit user confirmation — real context 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?

Three short sentences, front-loaded with the action and scope, then the precondition, then the confirmation protocol. Only mild redundancy with the schema's identical confirmed 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?

An output schema exists so return values need no explanation, and the confirmation flow is fully specified for a destructive tool. Minor gaps remain: what qualifies as 'draft or failed' content, and whether deletion cascades to related records.

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%; workspaceId is thoroughly documented in the schema, and confirmed's schema description duplicates the tool description. contentIds, however, is undocumented in both places — the description never explains what a content ID is or the 25-item batch cap, so it does not compensate for the 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 and resource with a meaningful scope restriction: 'Permanently delete draft or failed content.' That restriction distinguishes it from campaignstack_edit_content and campaignstack_get_content, though it does not explicitly name the sibling to prefer.

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

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

Gives a clear precondition ('Requires confirmed:true') and a concrete pre-call protocol: name what will be deleted, state it cannot be undone, wait for explicit yes. No exclusion of alternatives, but the usage 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?

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds genuinely new traits: the list row is removed immediately while entries drain asynchronously, and it is a permanent root-record deletion. This goes beyond the boolean hints, though the confirmation protocol is duplicated verbatim in the schema.

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

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

Three sentences, front-loaded with purpose, scope, and behavior in a logical order. Slightly undermined by the confirmation sentence being repeated word-for-word in the confirmed parameter description, but within the description itself nothing is wasted.

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

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

With an output schema present and annotations covering the safety profile, the description supplies everything an agent needs: purpose, scope, async behavior, permanence, and the confirmation gate. Nothing material is missing for correct invocation.

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

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

Schema coverage is 67%, and workspaceId plus confirmed carry rich schema descriptions. The description only reinforces the 50-item cap on leadListIds and adds no syntax or format detail; leadListIds itself has no schema description, so the gap is only partly compensated. Baseline 3 for adequate but not value-adding param 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 specific verb and resource ('Delete ... lead lists') with explicit scope ('up to 50', 'from the bound workspace'). This is clearly distinguishable from siblings like campaignstack_get_lead_lists and campaignstack_edit_lead_list without opening any schema.

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

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

Gives a strong precondition for invocation: name exactly what will be deleted, state it cannot be undone, and wait for an explicit yes. It does not name alternative tools or contrast with soft-delete paths, so it falls short of a full when/when-not/alternatives treatment.

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

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

Annotations already flag destructiveHint=true, but the description adds substantial context beyond them: the delete is permanent and irreversible, it is a root record, linked watch pointers are cleared, batches are bounded, and results come back per item with partial failures surfaced. That is exactly the disclosure a mutation tool 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?

Front-loaded with the action, then the guardrails, then the response contract. It is slightly repetitive in restating the confirmation requirement that also appears in the confirmed parameter schema, but every sentence carries operational weight.

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 an output schema present, the description rightly avoids describing return shape in detail while still noting per-item results and partial-failure reporting. Combined with the confirmation contract and cascade behavior, an agent has enough to call this safely; only ID formatting guidance 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 67%, with agentIds carrying no inline description and workspaceId and confirmed well documented. The description adds the batch bounding and one-result-per-item semantics, but says nothing about agent ID format or limits beyond what the schema's maxItems implies. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Delete signal agents') plus the mechanism ('archive/remove contract and clearing linked watch pointers'). The resource is distinct enough from siblings such as delete_signal_watch and edit_signal_agent, but no sibling is named explicitly, so it falls 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?

Gives a clear precondition ('Call this only after the user confirms the exact agents to remove') and an explicit confirmation ritual. It does not, however, point to an alternative when the user merely wants to modify an agent (e.g., edit_signal_agent), which would be the natural when-not case.

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

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

Annotations declare destructiveHint=true, and the description adds real value beyond that: the archiving mechanism, the permanence of the operation, the required explicit user confirmation, bounded batching, and partial-failure reporting. The only wobble is mild tension between 'archiving' and 'permanently deletes a root record'.

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

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

Front-loaded with the action and mechanism, and sized reasonably for a destructive tool. There is some duplication: the deletion/confirmation instructions are repeated almost verbatim in the confirmed parameter description, costing a little density.

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 safety workflow, batch bounds, and even touches on return semantics ('one result per requested item', partial failures) despite an output schema existing. For a destructive batch tool this is close to complete; missing only return-shape detail that the output schema carries.

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%; workspaceId and confirmed are well documented in the schema itself, but watchIds has no description in either place. 'Batch edits are bounded' restates the maxItems:25 constraint without adding meaning, so the description adds little beyond the schema.

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

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

States a specific verb and resource ('Delete person signal watches') and explains the mechanism ('by archiving them so they no longer refresh'), which separates it from edit_signal_watch. It does not explicitly route against sibling delete tools (delete_signal_agent, delete_company_employee_watch), 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?

Gives an explicit precondition ('Call this only after the user confirms the exact watches to remove'), which is clear usage context. It does not name an alternative tool for modifying rather than removing watches, so no exclusion/alternative routing.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds substantive context beyond them: the deletion is permanent AND cascades to associated records, and a confirmation flag is mandatory. The only gap is that it doesn't describe the failure/response shape, which is partly covered by the 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?

Two short sentences, both load-bearing: the first defines the action and its blast radius, the second defines the safer alternative. No filler. Slightly terse on return/cascade edge cases, but nothing is wasted.

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

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

With annotations covering the destructive profile, an output schema covering returns, and 3 params of which two are documented in the schema, the description's remaining job is scope and safety framing — both delivered. Only minor omission is guidance on what happens on a failed/partial cascade.

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%, with the confirmed and workspaceId parameters already well documented in the schema (including the multi-workspace fallback behavior). The description adds the confirmed:true requirement, but says nothing new about workflowId or workspace resolution, so this sits at the baseline where the schema does most of the work.

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

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

States a specific verb+resource (delete one workflow) and immediately scopes it ("and its associated records"), which is the key semantic difference from a soft disable. It also names the sibling alternative, so an agent can distinguish it from edit_workflow without opening either schema.

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

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

Explicitly routes the agent: use edit_workflow set_enabled:false when the goal is pausing without losing history, and use this tool only for permanent removal. The precondition (requires confirmed:true) is also stated up front.

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, but the description adds that this deletes a ROOT record (implying cascade/side effects), that it cannot be undone, and that a confirmation gate is enforced. That is meaningful context beyond the flags.

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

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

Three short sentences, no waste, with the irreversible/root-record warning front-loaded before the confirmation workflow.

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?

Output schema exists so return values need no explanation; annotations carry the safety profile; the description covers the remaining agent-facing concerns (irreversibility, root-record scope, confirmation gate) for a 3-param destructive tool.

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

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

Schema coverage is 100% and the confirmed parameter's schema description is verbatim identical to this text, so the description adds no new parameter meaning. memoryId and workspaceId semantics are left entirely to the schema. Baseline 3 is correct.

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

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

States a specific verb+resource+scope: 'Permanently delete one workspace memory candidate or active fact.' An agent can distinguish it from campaignstack_edit_workspace_memory and campaignstack_get_workspace_memories immediately.

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

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

Gives an explicit precondition chain (requires confirmed:true; name what will be deleted, state irreversibility, wait for explicit yes), which defines when the tool may be called. It does not name edit_workspace_memory as the non-destructive alternative, so it falls short of full alternative routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and non-open-world, so the safety profile is covered. The description repeats that ('Read-only diagnostic only') rather than adding new behavior, though listing the diagnostic dimensions tells the agent what reasoning is exposed. No rate limits, auth requirements, or failure modes are 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 tight sentences with the core purpose front-loaded and the read-only constraint appended. No 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?

An output schema exists, so return-value detail is rightly omitted, and annotations cover safety. But with 3 of 4 parameters undocumented and no routing guidance to sibling diagnostic or retry tools, the definition leaves real gaps for an agent trying to call 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 description coverage is only 25% (just workspaceId). The description says 'one lead' but never disambiguates leadId versus profileUrl, which appear to be alternative lead identifiers, nor explains workflowId's expected format. Only workspaceId is documented, and that documentation lives in the schema, not the description.

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 ('Explain why one lead did or did not enter one workflow') and scopes it to a single lead/workflow pair, which distinguishes it from siblings such as campaignstack_trigger_workflow, campaignstack_retry_workflow_entries, and campaignstack_get_workflows. The enumerated analysis dimensions (score, dedup, exclusions, provider filters, verdict) make the output intent 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?

'Read-only diagnostic only' implies this is for investigation rather than mutation, which is useful framing. However, it never says when to reach for this versus trigger_workflow, retry_workflow_entries, or get_workflows, nor does it state prerequisites. Usage is implied, not specified.

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

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

Annotations already flag destructive/openWorld/non-idempotent, and the description adds substantial context beyond them: enabling a watcher starts drafting outbound messages, the first enable creates the review-first workflow, later calls pause/resume, one watcher per kind across all workspaces, and delete clears session/proxy/budgets/credentials. It even documents error codes (DUPLICATE_*_EXTERNAL, AGENT_ACCOUNT_UNAVAILABLE). Slightly dense but very informative; a 5 would need explicit reversibility/permission constraints.

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

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

Front-loaded with the core purpose and then walks each operation, avoiding redundant restatement of annotations. It is a dense run-on paragraph that could be broken per operation, which keeps it from a 5.

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

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

Given an output schema exists (returns needn't be described) and annotations cover the destructive profile, the description supplies everything an agent needs: operation selection, confirmation requirements, cross-workspace watcher constraints, and error-code behavior.

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

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

Schema coverage is 50%, and the description compensates by explaining the semantics of each operation's payload (ownerWorkspaceId as the payer, watcher kinds and their behaviors, the confirmation flag). It doesn't clarify the 'enabled' toggle semantics or workspaceId defaults beyond schema, so it's not a full 5.

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

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

Opens with a specific verb+resource ('Edit one connected LinkedIn account') and then enumerates the three distinct operations (set_owner_workspace, set_watcher, delete) with what each does. It also names the sibling it differs from (edit_workspace_accounts unlink), so an agent can route correctly 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?

Explicit when-to-use for every operation: set_owner_workspace for changing the paying workspace, set_watcher for toggling watcher kinds, delete only after naming the account and getting explicit confirmation. It even states the confirmation protocol ('get a yes first') and the alternative unlink path.

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 (destructive=true, idempotent=false), it discloses cost implications ('can spend credits, paid provider quota, or model-backed work'), that deletes cascade and cannot be undone, that confirmed:true is required for archive/deletes, that archive does not send messages, and edge cases like a second watch returning enabled:false with a disabledReason. This is richer behavioral context than annotations alone 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 core operations are front-loaded, but the description is a dense, run-on block that packs cost, deletion, restore, and watch behavior into long compound sentences. Nearly every clause is informative, yet the lack of paragraphing or bullets makes it harder to scan than it needs to 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 15-variant polymorphic operation tool with an output schema already defined, the description covers the safety-critical operations (delete/archive confirmations, irreversibility), cost signaling, and the restore path. It is largely complete, with minor gaps in per-op field detail that the schema carries.

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

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

With only 33% schema description coverage, the description compensates for the most non-obvious parameters: rescore/rescoreLeadIds semantics, topic addressing by topicId or exact taxonomy name, search_watch enabled/accountIds behavior, and bounded score weights. Many nested data fields (icpId, titles, persona goals, etc.) are left to the schema, so it does not fully close the coverage gap.

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

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

The opening sentence names specific verbs (create, update, archive, unarchive, edit, delete) and the exact resources (ICP, persona, roadmap phase, topic, search watch, signal weight, automation state). It clearly distinguishes itself from read siblings like campaignstack_get_campaigns and from neighboring edit_* tools by scoping to campaign components.

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 concrete when-to-use routing: 'Use archive to stop work without deleting history', 'unarchive reverses it and needs no confirmation', and points to campaignstack_get_campaigns' guidanceHistory include for restoreVersionId. It does not, however, explicitly exclude or contrast sibling tools such as edit_workflow or edit_signal_agent, leaving some selection inference to the agent.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and notably idempotentHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it is a per-workspace overlay patch and explicitly does NOT touch shared firmographics, defining the blast radius of the write. It omits partial-failure behavior and whether omitted fields are cleared.

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

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

Two sentences, zero waste, with the scope of the mutation front-loaded and the negative scope constraint immediately after. Nothing redundant.

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

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

An output schema exists, so return values need not be explained, and workspaceId resolution is fully covered by the schema description. For a bounded mutation tool the description covers resource, field scope, limits and non-effects; only edge-case semantics (partial failure, clearing fields) are absent.

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 50%: workspaceId is richly documented in the schema while the nested companyId/tags/notes items have no descriptions. The description names the patchable fields and the 50-item cap (the cap is already in the schema as maxItems), so it adds mild clarification rather than compensating for the undocumented nested 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?

States a specific verb (patch) and a specific resource (per-workspace company overlays), and clarifies the exact mutable fields (tags/notes) plus the blast radius (not shared firmographics). It is clearly separable from get_companies, refresh_companies and enrich_companies, though it does not name a sibling explicitly.

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

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

Usage is implied by the scope statement (edit tags/notes on up to 50 companies), and the negative clause 'does not mutate shared firmographics' nudges the agent toward other tools for firmographic changes. However, there is no explicit when-to-use/when-not or named alternative, so guidance stays at the implied level.

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

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

Adds real behavioral context beyond the annotations: batch edits are bounded, one result is returned per requested item, and partial failures must be surfaced rather than reporting the whole batch as successful. The annotations only say readOnly=false, destructive=false, idempotent=false, so this partial-failure contract is genuine added value. Minor gap: it doesn't clarify permission or auth requirements.

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

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

Front-loaded action statement followed by trigger, exclusion, and batch/result semantics. Every sentence earns its place with 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?

An output schema exists, so return values need not be explained, and the description covers triggering, the delete alternative, batch bounds, and partial-failure reporting. The only residual gap is the absence of parameter-level detail to compensate for the 50% schema coverage.

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%; the description only vaguely maps to the two modes ('create' vs 'set_status') without naming the operations array, companyId, watchId, or status fields. The anyOf schema itself documents the mode structure, so the description adds little beyond what structured data 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?

States a specific verb and resource ('Create company employee watches or change their active/paused state') and explicitly names the sibling operation it is not ('does not delete watches; use campaignstack_delete_company_employee_watch'). An agent can distinguish it from related edit/delete watcher tools 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?

Gives an explicit trigger ('when the user asks CampaignStack to watch a company for new hires or pause/resume an existing company watch') and an explicit exclusion with the named alternative tool for deletion. Nothing 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 write (readOnlyHint=false), destructiveHint=false and non-idempotent, and the description is consistent with them ('reversible'). It adds genuinely non-schema behavior: bounded batches, one result per requested item, and partial-failure reporting rather than all-or-nothing success. It stops short of stating auth/permission requirements or what a paused watch does to in-flight signals.

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

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

Front-loaded with the operation set, then the routing exclusion, then return semantics. Four dense sentences with no filler, though the return/partial-failure sentence could be tightened.

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

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

An output schema exists, so return shape need not be described, yet the description still flags per-item results and partial failures—important for a batch tool. Combined with the sibling routing and reversibility note, an agent has everything needed to call this correctly for a multi-mode, nested-union schema.

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

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

Schema description coverage is only 50%, so the description has to compensate—and it does by mapping its prose operations onto the union schema's modes (create, set_status via pause/resume, set_accounts via LinkedIn account assignment). It does not clarify workspaceId scoping or the sendAccountIds vs linkedinAccountIds duality, which the schema itself covers.

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

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

States a specific verb+resource (edit competitor watches) and enumerates the concrete operations: create, pause/resume, assign LinkedIn observer accounts. It explicitly names the sibling it is not (campaignstack_delete_competitor_watch), so an agent can route correctly without opening another schema.

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

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

Gives an explicit when ('call this for reversible competitor watch changes') and an explicit when-not with the alternative tool named for the non-reversible case (deletion). This is the strongest form of 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 mark it as a non-read, non-idempotent, non-destructive mutation, and the description usefully adds that transitions are validated, results are returned per-operation, and nothing is published here. The per-operation result contract and the 'draft only' guarantee are genuine additions beyond the annotations, though reversibility and failure semantics of a partially-applied batch are unstated.

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

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

Five dense but purposeful sentences, front-loaded with the operation taxonomy before the generator and transition detail. No filler, though the generator examples are the densest part and could be tightened.

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

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

An output schema exists, so return-value explanation is unnecessary, and the description still covers the key agent-facing facts: batch-per-operation results, draft-only generation, and no publishing. Given the broad 25-item operation union, it is close to complete, missing only error/partial-failure guidance.

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

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

With only 50% schema description coverage, the description compensates by explaining copyFromId (duplicate), the generator.type variants and what each drafts from, and the notion of legal desired-state transitions. workspaceId semantics live in the schema. Inner operation fields like tags, mediaIds, and scheduledAt/autoSchedule still carry no prose meaning.

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

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

States a specific verb set and resource: create, update, duplicate via copyFromId, and desired-state transitions on content. It cleanly separates itself from delete_content and get_content by naming the write-side operations. It does not, however, differentiate itself from the sibling campaignstack_edit_draft, which an agent may reasonably confuse with post content editing.

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 conditional context for the generator branches (lead_magnet vs search_console_demand) and clarifies that generators only produce drafts. It does not state when to prefer this tool over edit_draft or get_content, nor any prerequisites or workspace-auth conditions beyond what the schema already carries.

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 idempotentHint=true, destructiveHint=false and readOnlyHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: that edits apply only to a *pending* scheduled message, that cancellation is part of this tool, and that this tool is deliberately not the send path. It omits limits (e.g. the 25-item cap) and permission requirements.

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

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

One dense sentence, front-loaded with the core 'what' before the sibling references. The parenthetical about scheduledMessages/id source is information-dense, though the packaging is a little thick for a single sentence.

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

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

Output schema exists, so return values need no explanation, and annotations carry the safety profile. For a mutation with 0 required params, the description covers both mutation paths and the id provenance. Only minor details (item limits, partial-failure behavior) are absent.

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

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

Schema description coverage is only 33% (workspaceId is the documented one). The description partially compensates by mapping the two undocumented arrays to their semantics and telling the agent where the scheduled message `id` originates (get_conversations with include.scheduledMessages). It still leaves the conversationRef shape and the edit-vs-cancel field constraints to the schema, so it is additive but not fully compensating.

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

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

States a specific verb+resource+scope: 'Batch small inbox state changes' covering two concrete operations (mark read, cancel/edit a pending scheduled send). It distinguishes itself from the two overlapping siblings by name, saying concerns route to campaignstack_send_message and ids come from campaignstack_get_conversations. An agent can place it correctly without opening any schema.

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

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

Gives clear when-to-use conditions ('mark conversations read, or cancel/edit a pending ... sendAt row') and explicitly names the alternative for the adjacent case: 'Sending remains campaignstack_send_message.' It stops short of stating exclusions against other edit_* tools, so it is strong context rather than a complete routing guide.

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 (which only say non-read-only, non-destructive, non-idempotent) by disclosing state outcomes: a pending draft stays pending, a scheduled message keeps its slot, and a job application keeps its status. It also clarifies that a human approval is recorded as an edit, which is genuine mutation-behavior context.

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

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

Front-loads the core action and scope, then layers routing and state semantics. It is dense and mostly earns its length, though the parenthetical explanation of the approval-recording mechanism is slightly verbose relative to 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?

With an output schema present, return values need no explanation, and the rich schema plus the description together cover kind, confirmation consequences, workspace resolution and state semantics. An agent has everything needed to call 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 description coverage is 80%, so the schema already documents kind, confirmed, workspaceId and updatedContent in detail. The description reinforces the 'one draft' scope and approval-neutrality but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Save new words on one draft') and immediately qualifies the scope as approval-neutral. It distinguishes itself from the sibling that actually approves/rejects/sends by naming campaignstack_decide_review, so an agent can pick it apart from the decision tool without opening either schema.

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

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

Gives explicit when-to-use conditions ('when the user asks to revise a draft for someone to sign off later, or to reword a message that is already approved and scheduled') and an explicit exclusion plus alternative ('It never approves, rejects or sends (campaignstack_decide_review does that)'). Nothing about routing is left to inference.

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

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

Goes well beyond the annotations by disclosing the additive-only constraint on child targets, that workspace restrictions cannot be released from a child, that batch edits are bounded, and that partial failures are reported per item. It still omits auth/permission requirements and any statement about reversibility of removals, so it falls short of a 5.

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

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

Front-loaded with purpose, then trigger conditions, then the key constraint, then batch/return semantics. Every sentence carries distinct information with 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?

Covers the tricky semantics of a multi-mode batch mutation tool (additive child policy, bounded batches, partial-failure reporting), and an output schema exists so return shape need not be explained. Missing only permission/reversibility context for what is a 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?

Schema coverage is 67% and the schema itself describes target.id, the target type enum, and workspaceId in detail. The description only restates the target types and the additive constraint, adding little parameter-level meaning beyond the structured 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?

States a specific verb (Edit) and resource (exclusion policy) plus the exact target scope (workspace, signal agent, workflow). An agent can distinguish this from the read-side sibling campaignstack_get_exclusions without opening the schema.

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

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

Explicitly names trigger conditions: add/remove blocked profiles, change filter rules, enable/disable exclusion rules. It does not name an alternative tool or state when not to use it, but the usage 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?

Annotations declare this a non-readonly, non-idempotent, non-destructive mutation. The description adds genuinely useful behavior beyond that: core/overlays are a full replacement rather than a merge, and restores are versioned. It still doesn't cover permission requirements, how omitted optional fields behave under replacement, or reversibility of an edit.

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

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

Three compact clauses, front-loaded with the action and resource, then target identifiers, then replacement/versioning semantics. No filler sentences.

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 10-parameter nested-object mutation with an output schema present, the description covers the core mechanics (identity targeting, full replacement, versioned restore) but omits the meaning of 'active' and 'readableSummary' and the exact restore flow from restoreVoiceVersionId to a version. Adequate but not complete.

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

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

Schema description coverage is only 10% across 10 parameters (only workspaceId is documented in the schema), so the description must carry the load. It clarifies the identifier alternatives, that core/overlays replace wholesale, and implies the version id for restores, but leaves 'active' and 'readableSummary' entirely unexplained and says nothing about the required 'language' format beyond the field 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?

States a specific verb pair (edit/restore) and resource (identity voice profile language), and scopes it to one language at a time, which distinguishes it from the bulk refresh sibling. It does not directly name campaignstack_refresh_identity_voice or campaignstack_get_identities, so the differentiation is implied rather than explicit.

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

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

Gives concrete invocation guidance about which identifier to supply (identityId, linkedinAccountId, or googleAccountId) and notes restores are versioned, which implies restoreVoiceVersionId usage. However, it never says when to choose this tool over campaignstack_refresh_identity_voice or campaignstack_get_identities, and no when-not conditions are given.

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

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

With annotations already covering readOnly, destructive, idempotent, and openWorld hints, the description adds meaningful mutation semantics: create binds to one account, update replaces searches only when queries is supplied and merges applicationProfile, pause stops new activity, and resume requires a usable account. It does not mention idempotency directly, but the operation-level behavior is well 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?

The description is front-loaded with the full operation set and remains dense without wasted sentences. Each subsequent sentence adds distinct behavioral or safety information about specific operations.

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

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

Given the high-complexity operations array, the available output schema, and the existing annotations, the description provides enough context for correct selection and invocation. It explains all operation modes and the key pre-call confirmation, while structured fields carry the remaining parameter and return-value details.

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 operation-level meaning beyond the schema, especially around update semantics, applicationProfile merging, pause/resume effects, and the outboundMode/applyEnabled safety condition. It does not cover workspaceId or every nested field, but the schema already documents many of those details and the description compensates for the highest-risk 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 description opens with a specific set of verbs and resource: create, update, pause, or resume job watchers. It also states the scope, 'one bounded request,' and each operation is distinguished by its effect. The operation set implicitly differentiates this tool from read/archive siblings, even though no sibling is named.

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

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

It gives clear operational context for create, update, pause, and resume, and adds a pre-call confirmation requirement when outboundMode is automatic or applyEnabled is true. It does not, however, name alternative tools such as archive_job_watcher or get_job_watchers or explain when to use those instead.

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

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

Annotations already declare the mutation profile (readOnly=false, destructive=false, non-idempotent), so the bar is lower. The description adds real behavioral context beyond that: the 50-member cap and the predicate-ownership rule governing whether add/remove is legal. It omits permission/reversibility details, keeping it out of 5 territory.

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, front-loaded with the operations and ending with the key constraint. Every clause carries meaning, though the phrasing is compressed enough to require a second read.

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?

An output schema exists, so return values need no explanation, and the description covers the critical set-vs-query distinction and the member cap. Given the complex nested query object and 5-way op enum, more op-specific guidance would help, but the core is complete enough to invoke correctly.

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

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

Schema coverage is only 14%, so the schema documents almost none of the 7 parameters. The description partially compensates by mapping the op enum values to intents (create/create_query/update/add_members/remove_members) and by implying name/query in 'update list metadata/query', but it leaves most parameter semantics implicit.

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 specific verbs and the resource (create set/query lead lists, update, add/remove members), so an agent immediately knows this edits lead lists. It does not explicitly differentiate itself from adjacent siblings like delete_lead_list or edit_leads, but the verb+resource pairing 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 gives a clear conditional rule: query-list membership is predicate-owned, and explicit add/remove only works on an editable set list. That tells the agent when add_members/remove_members will succeed vs fail. It stops short of naming an alternative tool for the query-list case, so it earns a 4 rather than 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 only say this is a non-read, non-destructive, non-idempotent write. The description adds substantive behavior the annotations cannot convey: metadata edits land in a workspace overlay rather than the global row, contact edits touch global rows only after membership proof, and linking is provenance-bounded to private leads. It does not cover partial-failure or per-lead error behavior, which keeps it out of the top band.

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 plus a batch limit, front-loaded with the core verb and scoped by patch type; every clause carries operational information. The heavy domain jargon ("provenance-bounded", "workspace overlays") is terse but not padded.

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

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

An output schema exists so return-value explanation is unnecessary, and the description plus annotations together cover mutation semantics, per-patch-type constraints, and the 50-lead cap. Missing only edge-case behavior such as what occurs when membership proof fails or when a leadId resolves to neither store.

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

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

Schema description coverage is only 50%, and the description does add the overlay-vs-global-row semantics for the metadata parameter that the schema never states. However, leadId, leadSource, and workspaceId receive no treatment in the description, and the contact/profileLink constraints it repeats are already spelled out in the schema.

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

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

States a specific verb+resource ("Apply bounded lead edits") and enumerates the three edit classes (metadata patches, contact patches, profile link/unlink), which separates it from read/enrich/import siblings like get_leads or enrich_leads. It stops short of naming an alternative, but the operation 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?

Usage is implied rather than stated: the text tells the agent that contact patches apply to global-row leads and profile link/unlink applies to private leads, which functions as implicit eligibility guidance. There is no explicit when-not and no named sibling to prefer for adjacent tasks such as enrichment or list management.

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 supply the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false); the description goes further by disclosing a real access-control constraint - user-key and OAuth callers can only touch their own rows plus legacy shared rows. It stops short of saying whether marking read is reversible.

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

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

Two tight sentences, front-loaded with the action and followed by the scope restriction - no wasted phrasing.

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

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

An output schema exists so return values need no explanation, and the description covers modes plus auth scoping. It leaves a small gap on interactions between 'all' and 'ids' for a mutation tool with no required parameters.

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

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

Schema description coverage is only 33% (workspaceId is documented; 'all' and 'ids' are bare), and the description compensates by explaining both modes and their target scope. However, it omits useful constraints such as the 25-id cap and whether 'all' and 'ids' are mutually exclusive.

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: 'Mark notifications read by ids' or mark all read for the workspace. An agent can distinguish this from the read-side sibling campaignstack_get_notifications, though no sibling is named 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 two operational modes (by ids vs. all for the workspace) are implied as branches, but the description never says when to prefer this tool over the read-only get_notifications sibling or any alternative, and lists no exclusions.

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

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

Annotations already flag destructiveHint=true, but the description adds meaningful context: archiving is 'permanent removal' equal to the delete tool and requires confirmed:true, plus batch edits are bounded and partial failures must be reported rather than masked. This goes beyond the structured fields, though the confirmed:true detail is also present in the schema.

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

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

Three dense sentences, front-loaded with the operation list, then the destructive/restore caveats, then batch-return behavior. Efficient and every sentence carries information, though the phrasing is somewhat packed.

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?

An output schema exists, so return values need not be detailed, yet the description still specifies one result per item and partial-failure reporting. Combined with the destructive confirmation guidance, it is complete enough for a complex multi-mode mutation tool, with only minor gaps around per-mode constraint limits.

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?

Top-level schema coverage is 50% and the operations array is documented only by structure, so the description compensates by explaining what each mode does and where versionId originates (get_signal_agents include.guidanceHistory). It adds semantics the schema alone does not convey.

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

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

The description names the resource (signal agents) and enumerates every supported operation mode: create, update account/script, pause/resume, replace exclusions, and restore a prior agentScript version. It explicitly distinguishes the archive path from campaignstack_delete_signal_agent, so an agent can tell it apart from siblings without opening a schema.

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

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

It routes the agent to sibling tools for context: restore_guidance needs a versionId from campaignstack_get_signal_agents include.guidanceHistory, and status 'archived' is equated with campaignstack_delete_signal_agent. Clear conditions are given, though it does not enumerate when NOT to use this tool for the create/update modes.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the safety profile is covered. The description adds meaningful context beyond that: batch edits are bounded and partial failures must be reported per item rather than as a whole-batch success. Missing auth/rate-limit details, but the partial-failure contract 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?

Front-loads the core action in the first sentence, then layers usage, exclusions, and behavioral notes. Five sentences, all informative, though a bit more compact phrasing could tighten it further without loss.

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 an output schema exists, return values need not be explained. The description covers purpose, usage, alternatives, batch bounds, and partial-failure behavior. WorkspaceId semantics are full in the schema. Complete enough for a batch mutation tool, though it could mention idempotency or re-run implications.

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 50% (only workspaceId is documented). The operations parameter has no schema description, but its anyOf structure and mode constants are self-explanatory. The description's 'create person signal watches or change their active/paused state' maps to the two modes but adds little beyond what the schema already conveys. Baseline 3 is appropriate.

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

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

States a specific verb (create/change state) and resource (person signal watches), and explicitly contrasts with the deletion sibling tool. An agent can distinguish it from similar edit tools like campaignstack_edit_company_employee_watch 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 when-to-use conditions ('user asks CampaignStack to watch a lead for profile changes or pause/resume an existing person watch') and a clear when-not with the named alternative ('does not delete watches; use campaignstack_delete_signal_watch for removal'). No inference required.

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

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

Annotations already cover the safety profile (readOnly=false, destructive=false, idempotent=false), so the bar is lower. The description adds genuinely non-obvious context the annotations do not: the required key type and the fact that workspace keys are rejected. It does not discuss idempotency or reversibility, so it falls short of a 5.

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

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

Two compact sentences, front-loaded with the scope ('calling user's ... only') before the auth constraint. 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?

An output schema exists, so return values need no explanation, and the auth requirement is covered. But for a tool whose sole parameter is a nested object with a 'clear' flag and multiple enums, the description leaves the mutation semantics unexplained, which is a notable gap for a write 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 effectively 0% for the nested object's meaningful fields (clear, value, category, weeklyReport); only the nested workspaceId carries a description. The description merely restates the parameter name ('notification preferences') and adds no semantics for the 'clear' flag, the immediate/off value, or the category enum. With low coverage, the description fails to compensate.

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

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

States a specific verb and resource with scope: 'Edit the calling user's notification preferences only.' The word 'calling user's' and 'only' usefully delimit it. However, it does not explicitly differentiate from the adjacent sibling campaignstack_edit_notifications, which an agent could easily confuse it with.

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

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

Gives a clear precondition and an exclusion: a user API key is required, and workspace keys cannot change personal preferences. That is real when/when-not guidance for auth context, though it never names the alternative tool to use for workspace-level preferences.

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 the safety profile (readOnly=false, destructive=false, openWorld=false). The description adds meaningful behavior beyond that: operations run as a batch and "Each operation returns independently," which tells the agent results are per-item rather than all-or-nothing. 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 capability list is front-loaded in the first sentence, followed by the routing constraint and the per-operation return note. Dense but every clause carries information; 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?

For a multi-op batch tool with a rich schema and an output schema present, the description covers the operation set, the sibling boundary, the versionId source, and partial-failure semantics. Return-format explanation is rightly delegated to the output schema; only deeper mutation semantics (e.g., what set_meta overwrites) are unstated.

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

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

Schema coverage is 100% so the baseline is 3, but the description goes further by semantically unpacking the op variants (create, set_meta/enable, set_linkedin_accounts, restore_guidance) and specifying that versionId comes from a guidanceHistory payload. That mapping adds meaning the raw const values alone don't convey.

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

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

The description opens with a precise list of verbs and resources this batch tool performs: create workflows, edit metadata, enable/pause, set LinkedIn account pools, set email sender account, set outreach intents, and restore a guidance version. It also explicitly distinguishes itself from the sibling campaignstack_edit_workflow_graph, so an agent can tell the two apart 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 names the key alternative and the condition that selects it ("Graph changes belong in campaignstack_edit_workflow_graph") and points to campaignstack_get_workflows include.guidanceHistory as the source of versionId. It gives clear context but does not address other adjacent tools (trigger/delete workflow) or when-not to use this one at all.

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 the write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower, yet the description adds real context: atomicity, that invalid graphs are rejected before persistence, and that active-lead safety is still enforced by the backend. It stops short of describing concurrency/rate-limit behavior or undo semantics.

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

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

Every sentence carries information — mode semantics, validation behavior, safety guarantee, and post-write optimization — and the core 'atomically patch or replace' statement is front-loaded. Slightly dense, but 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 complex nested mutation with an output schema present, the description covers the essentials: the two modes, validation-before-persistence, safety enforcement, and post-write optimization. Return values are the output schema's job, so omission there is fine; only cross-sibling positioning is thin.

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

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

Schema description coverage is only 33%, so the description must compensate, and it does for the critical parameters: it explains mode semantics and that patch edges 'replace the non-anchor edge set when supplied'. It also notes the optional split-node optimization. It does not add meaning for workflowId or the graph/patch node subfields beyond what the schema shows.

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 (edit/patch/replace) and a precise resource (one workflow graph), and it distinguishes the two modes up front. An agent can tell this apart from the metadata-oriented campaignstack_edit_workflow without opening either schema.

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

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

It clearly explains the two operating modes — replace supplies the full graph, patch starts from the current graph and upserts/removes nodes — which tells the agent which mode to choose. It does not, however, state when to prefer this tool over sibling workflow tools like campaignstack_edit_workflow.

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 declare write/not-readonly, non-destructive, non-idempotent), the description adds meaningful behavior: 'Only supplied components change' (partial-update semantics), branding affects client-facing shared artifacts only, compliance toggles a fixed lawful-basis notice, and restores are versioned. These are substantive side-effect disclosures, though non-idempotency is not called out.

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-loaded with the action list and scoping rule, with no obvious filler. The final proposal-reading sentence is useful but reads as a slightly tacked-on procedural note.

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

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

With an output schema present, return values need not be explained, and annotations already carry the safety profile. The description covers the behavioral essence of each write path, though the low parameter coverage means nested-field semantics rely on the schema rather than the description.

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 low (17%), so the description should compensate. It names the top-level components (settings, branding, compliance, playbook version, proposal decision) and adds the partial-update rule, but says nothing about nested fields such as jevFeatures, offerContext, or outreachIntents, leaving much to 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 enumerates specific verbs and resources: writing settings, branding, compliance, restoring a playbook version, and accepting/rejecting a proposal. It clearly conveys this is a multi-purpose write tool, though it does not explicitly distinguish itself from adjacent siblings like campaignstack_propose_workspace_playbook_change or the edit_workspace_* family.

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 one explicit routing instruction ('Read the pending proposal with campaignstack_get_workspaces' playbookProposal include before deciding it'), which is a real precondition for the proposal path. However, it offers no when-not guidance or differentiation from the proposal-creation sibling, so usage for the other write paths is only implied.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false and readOnlyHint=false. The description adds real value beyond that by clarifying 'Nothing is re-authenticated or sent' — an agent learns no OAuth flow is triggered and no outbound messages occur, which is not derivable from the structured fields. It still omits permission requirements and side effects on campaigns referencing an unlinked account.

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 with no filler; the action is front-loaded and the clarifying constraint follows immediately. 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?

An output schema exists, so return values need no explanation and the workspaceId resolution rules are covered in the schema. However, for a mutation tool the description never says what happens to downstream artifacts when an account is unlinked, nor does it mention the 25-operation batch limit — meaningful omissions, though the annotations carry the safety profile adequately.

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?

Coverage is 50%: the schema fully documents workspaceId including the cs_/csu_ key rules, while the operations array carries no description. The description adds nothing about parameter semantics — it doesn't explain op values, the 25-operation cap, or what accountId must reference — though the nested enums and maxItems make operations largely self-describing, so the gap is real but not severe.

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 pair (link/unlink) plus the resource (already-connected LinkedIn/Google accounts in a workspace), which is concrete enough to act on. The word 'already-connected' implicitly separates it from campaignstack_connect_account, but no sibling is named, so the differentiation is left to inference.

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 phrase 'already-connected' implies the tool is only for re-associating existing accounts, suggesting connect_account handles new connections, but this is never stated and no condition or alternative is named. Usage is implied rather than guided, and nothing says when *not* to use it.

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

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

Annotations declare destructiveHint=true, but the description adds valuable context beyond them: it clarifies that disconnect deletes the workspace's stored credentials and that neither unlink nor disconnect undoes provider-side data already sent. This exceeds the annotation baseline meaningfully.

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: the first enumerates the operations, the second delivers the irreversible-data caveat. No waste, front-loaded action.

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 multi-operation tool with an output schema present, the description covers the operations and the key irreversibility caveat. It could go further on the fromWorkspaceId parameter and confirmDisconnect flag, but the core behavioral risk is disclosed.

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 is fully documented in the schema with rich omission logic, while the operations array fields (op, provider) have no descriptions. The description names the three op values but does not explain fromWorkspaceId or confirmDisconnect, leaving some parameters undocumented but doing better than the raw schema.

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

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

States specific verbs (link, unlink, disconnect) and resource (integration into/from workspace) with a clear three-way scope. An agent can distinguish this from campaignstack_configure_integration and campaignstack_edit_workspace_accounts.

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 three operations are enumerated but there is no explicit guidance on when to choose link vs unlink vs disconnect, nor any routing to sibling tools like campaignstack_configure_integration. Usage is implied by the operation names rather than stated.

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

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

With destructiveHint=true and non-idempotent annotations already set, the description adds real value: it explains that certain ops require explicit confirmation because they affect another person's access or send/cancel email, and that results are per-operation. It does not clarify whether partial batch failures roll back or how clientOperationId affects retry safety.

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

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

Three tight sentences, front-loaded with what the tool does, then the confirmation requirement, then the exclusion. No 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?

For a destructive multi-op mutation with an output schema, the description covers the safety-relevant requirements well. Remaining gaps are minor: batch size limits, idempotency/retry behavior via clientOperationId, and whether operations are applied atomically.

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 is richly documented in the schema, but the description does not discuss clientOperationId, the 25-operation batch cap, or ordering/atomicity semantics of the operations array. It does justify the confirmed field for three op types, which adds meaning beyond the schema — enough for baseline-plus, not full 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 names a specific verb (apply/edit) and resource (member and invitation operations) and enumerates the operation families — removes, invitations, revocations, role changes. It is clear, though it doesn't explicitly contrast with any sibling (there is no obvious competing member-editing tool in the sibling list, so differentiation is less critical here).

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

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

It states a concrete precondition (confirmed:true for removes, invitations, revocations) with the reason, and explicitly excludes admin/owner grants, which is genuine when-not guidance. It doesn't say what to use instead for those grants, so it stops short of a full routing instruction.

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=true, and destructiveHint=false, so the safety profile is covered. The description adds the practically important consequence – the memory becomes active in future prompts – and confirms idempotent behavior via the no-op case.

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

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

Two short sentences with zero filler; the core action is front-loaded and the edge case follows. 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?

An output schema exists so return values need not be explained, and annotations cover the mutation/idempotency profile. The description supplies the state transition (pending -> active) and the no-op case, leaving little an agent needs missing, though it is silent on any confirmation or permission requirements.

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%, with the workspaceId description itself explaining the cs_/csu_ key semantics and multi-workspace error behavior. The description adds nothing beyond the schema, 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 precise verb+resource: applying (activating) a pending workspace memory candidate. The effect on future prompts is spelled out, making it distinguishable from get/delete workspace memory siblings. It stops short of naming the sibling it supersedes (e.g. get_workspace_memories as the source of the candidate).

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 'no-op when already active' clause gives a useful precondition, and the schema points to campaignstack_get_workspace_memories as the source of memoryId. However there is no explicit when-to-use guidance relative to siblings like propose_workspace_playbook_change or refresh_workspace_playbook, so usage is only implied.

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

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

Annotations already declare non-read-only, open-world, non-idempotent, non-destructive, but the description adds genuinely useful behaviors beyond them: firmographics are shared public-domain data, and provider/API-key failures are surfaced per company rather than failing the whole batch. It stays silent on whether results are persisted and on cost implications of repeated calls.

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; the operational fact (enrichment, batch limit) is front-loaded and the partial-failure note follows. The public-domain-data clause is somewhat terse and its purpose (privacy/storage guidance?) could be clarified, keeping it short of a 5.

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

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

An output schema exists, so return values need no explanation, and partial-failure behavior is covered. Yet the description leaves important gaps: the provider/clayRoutineId contract, whether existing data is overwritten, and how this differs from refresh_companies.

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 25% (workspaceId is documented, the rest are not). The description never mentions provider (apollo/clay enum with a default), clayRoutineId, or workspaceId, so the undocumented clayRoutineId – presumably required when provider=clay – is left entirely opaque.

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

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

Names a specific verb+resource ('Run provider firmographic enrichment ... for companies') and gives the 25-company batch cap. It does not, however, distinguish this from close siblings like refresh_companies, edit_companies, or enrich_leads, so an agent can't route purely from the description.

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?

No statement of when to use this versus refresh_companies / enrich_leads / get_companies, nor prerequisites (does it overwrite existing firmographics? should it run only for un-enriched companies?). The only guidance-like content is the batch-size limit.

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 openWorld/non-idempotent/non-destructive. The description adds real value beyond them: per-lead provider errors are returned independently, and billing is per result found in each mode. The per-result charge implicitly warns that re-running costs again, which is meaningful for a non-idempotent 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 final sentence repeats information already stated in the opening ('Email is on by default', phone charged only when requested), burning a whole sentence on redundancy. The cost-mode and estimate_cost guidance is front-loaded reasonably, but the duplication is wasteful.

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

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

An output schema exists, so return values need not be explained, and the description covers the key behavioral facts an agent needs: scope cap, defaults, independent per-lead errors, and billing model. Minor gaps remain around provider choice and non-listed parameters.

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 20% and several parameters (provider, clayRoutineId, workspaceId) get no description coverage. The text does clarify include.email default true and include.phone default false with its cost implication, but it leaves the provider selection and clayRoutineId semantics unexplained.

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 ('Run contact enrichment ... leads') with a clear scope cap of 25. The resource noun distinguishes it from campaignstack_enrich_companies, but the description never names a sibling explicitly. Clear enough that an agent knows what it 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?

Gives useful pre-commit guidance by pointing to campaignstack_estimate_cost with variant/variantCounts, and clarifies the email-default/phone-opt-in condition. It never states when to choose this over adjacent tools like refresh_leads, get_lead_enrichments, or enrich_companies, so usage is only implied.

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