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 flag destructive/openWorld but the description adds far more: the comment is public and stays under the owner's name, there is no draft state and nothing to recall, one person per call, daily limits count already-queued sends, and a paused or challenged account refuses the send. These are exactly the operational facts 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?

Long, but front-loaded with purpose and then ordered by importance (identity, wording source, account, then safety and limits). Nearly every sentence carries decision-relevant information, though a few safety points ('no draft state and nothing to recall') could be tightened.

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

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

For a high-stakes public write with a low-coverage schema, the description supplies the prerequisites (approval, account, identifier choice), the send semantics, and the failure/limit conditions. An output schema exists, so return values need not be explained. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is only 43%, but the description compensates well for the important params: it explains leadId is the supported identifier while profileUrl works for existing workspace people, confirms platform is currently 'linkedin', constrains commentText to owner-approved wording, and points accountId at get_accounts. workspaceId and idempotencyKey are left to the schema's own descriptions, which is a minor residual 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 precise verb+resource+scope: 'post a comment on a lead's most recent post from a connected LinkedIn account.' This clearly separates it from siblings like campaignstack_send_message, campaignstack_like_post, and campaignstack_send_inmail without the agent needing to open 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 an explicit trigger ('when the user has approved specific comment wording for a specific lead's post') and names concrete alternatives for adjacent cases: campaignstack_craft_message for drafting and campaignstack_submit_comment_for_review for parking. It also explains the correct bulk path (edit_lead_list + trigger_workflow) and why a loop is wrong.

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 behavior beyond the annotations: secrets are validated, never echoed back, and the tool is non-OAuth because it accepts secrets. That complements the write/idempotency hints meaningfully, though it doesn't state what a replace does to prior credentials.

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

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

Three tight sentences, front-loaded with the action and scope, with no filler. The routing note and the secret-handling note each carry distinct value.

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

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

With an output schema present, return values need no explanation, and the description covers the security posture and routing constraint. The main residual gap is whether replacing an integration silently overwrites existing credentials or requires removal first.

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 workspaceId semantics and credential nesting are already documented in the schema. The description reinforces 'provider-nested credentials' 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 pair ('Store or replace') and resource ('one provider integration') plus the credential shape. An agent can tell it apart from read siblings like get_integrations, though it never names edit_workspace_integrations or connect_account 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 a clear usage rule: connected apps are told to send the user to workspace settings instead of calling this tool, and it explains the non-OAuth rationale. It stops short of naming the alternative API tool, so it is context-rich but not full when/when-not routing.

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

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

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

Beyond the annotations, the description discloses the no-send contract, the returned sent:false signal, the requirement to read the draft back, the explicit-approval workflow for sending, and the booking:false schedulingAcceptance behavior. These details materially help an agent understand what the tool will and will not do.

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

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

The description is front-loaded with the core no-send behavior, then adds approval and scheduling context. The four sentences are dense and none appears 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?

The output schema and annotations already cover return shape and safety, and the description adds useful workflow and scheduling context. However, for a 17-parameter tool with low schema description coverage, it leaves too many input semantics unexplained to be fully complete.

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

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

Schema description coverage is only 29% across 17 parameters, so the description needs to compensate, but it mostly repeats the enum values for channel and kind. It does not explain the roles of leadId, template, instructions, conversationMessages, postContent, meetingKind, or several other inputs.

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

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

The description states a specific verb and resource: 'Draft one outbound message.' It also distinguishes the tool from send/action siblings by saying it works 'without sending anything' and that a separate send tool is needed after approval, while enumerating the supported channels and kinds.

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 says to use this tool for drafting and to use a separate send/action tool only after explicit approval, and it notes that scheduling is never automatic. It stops short of naming the exact sibling send/action tools or clarifying when to prefer edit_draft, explain_draft, or preview_craft_prompt.

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 only the generic mutation profile (readOnly=false, openWorld=true, idempotent=false, destructive=false), and the description adds the operationally important traits: the auth requirement, the workspace-key restriction, single-build concurrency, free-account quota, the immediate workspaceId plus optional generationId return, and that outreach stays dormant until an account is linked. This is behavioral context an agent cannot get from the annotations.

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

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

Front-loads the core action and the what-gets-built payload in the first two sentences, then moves through per-parameter conditionals and constraints. It is dense and runs long as a single block, but nearly every sentence carries a distinct rule (goal fallback, name fallback, auth model, build concurrency, quota) rather than padding.

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

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

For a complex, zero-required-param creation tool this covers everything an agent needs: input conditionals, auth prerequisites, quotas, concurrency, the immediate return values, and the follow-up tool (campaignstack_get_workspaces) for tracking the build. The output schema exists, so return-value shape is correctly left to it.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description contributes meaning beyond the schema: it explains what goal becomes when omitted (written from website and profile), and contrasts the website path (no LinkedIn needed) against the profile path (requires the user's connected account). Some statements, such as the name fallback, duplicate the 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+resource ('Create a workspace and build it') and enumerates exactly what the build produces: company context, playbook, a first campaign with ICP, a workflow, and a lead pool. The purpose is unmistakable, but the description never differentiates itself from the similarly-named sibling campaignstack_onboard_workspace, leaving that distinction 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?

Explicit when-to-use rules for every input: pass goal only when the user stated the purpose, omit name unless the user chose one, website alone suffices, a profile URL requires a connected LinkedIn account, and neither URL yields a blank workspace that must be named. It also states entry prerequisites (user key or signed-in connection; a workspace key cannot create another) and limits (one build at a time, one workspace on a free account).

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/openWorld/non-idempotent, and the description adds what they cannot: approved workflow messages go out later on account pacing (hours), priority jumps the queue but still respects account states (paused/expired refused with error), and confirmed:true is mandatory because a real message or application may be submitted. No contradiction with the destructive annotation.

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

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

Front-loaded with the core action and the sibling alternative first, then kind-specific detail. Dense but every clause carries operational consequence; only the kind-specific paragraph runs long and could be tightened slightly.

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

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

For a 9-parameter destructive tool with an output schema, the description covers pacing, priority semantics, kind branching, confirmation, and rejection reasons. The remaining gap is what edit_and_approve's updatedContent means for the workflow kind and what a reject returns, though the output schema covers return shape.

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

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

At 67% schema coverage the description earns credit for documenting the otherwise opaque updatedContent shape for job_application ({ letter?, answers?: [{question, answer}] }) and for explaining priority constraints beyond the schema text. It leaves entryId/decision and workspace resolution to the schema, which is reasonable, but the workflow-kind use of updatedContent is not addressed.

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 (approve, reject, edit-and-approve) against a precise resource (one pending review) and immediately names the sibling it is not (campaignstack_edit_draft). An agent can distinguish it from nearby review/draft tools 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?

Explicitly routes the agent: use campaignstack_edit_draft when a revised draft needs human sign-off instead of a decision. It also gives a when/when-not rule for priority (only when the user asked for immediate send, and tell them) and states that priority cannot be combined with reject or job applications.

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 flag destructive/openWorld, and the description adds real depth beyond them: delete wipes session/proxy/budgets/credentials across every workspace, enabling a watcher starts drafting outbound messages, one watcher per kind is enforced globally (DUPLICATE_*_EXTERNAL), and a live session is required (AGENT_ACCOUNT_UNAVAILABLE). This is exactly the kind of context annotations cannot carry.

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

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

Front-loaded and organized around operation=, with each sentence carrying distinct operational content. It runs long as a single dense paragraph and would scan better as bullets, but little is truly 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?

Given four operations, a nested operation union, destructive semantics, and an output schema, the description covers all decision-relevant behavior: prerequisites, cross-workspace constraints, confirmation rules, and the difference from the sibling unlink tool. Nothing an agent needs to call it safely is missing.

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

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

Schema coverage is 75% and already documents the operation union well. The description still adds meaning the schema doesn't: confirmation preconditions for delete/set_watcher, the person-key requirement for google scheduling hours, and the error semantics of DUPLICATE_*_EXTERNAL and AGENT_ACCOUNT_UNAVAILABLE.

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 names every operation it supports (set_owner_workspace, set_watcher, delete, set_scheduling_hours), clearly separating it from the sibling campaignstack_edit_workspace_accounts. Minor ding for the opening framing as LinkedIn-only when the schema also accepts platform=google, though the last sentence corrects this.

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

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

Explicit routing per operation, plus explicit exclusions and alternatives: delete vs. campaignstack_edit_workspace_accounts unlink, and the requirement to get a yes/explicit confirmation before destructive or outbound-drafting changes. 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?

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 flag destructiveHint=true and non-idempotent, and the description adds real detail beyond them: which operation is destructive (delete), the confirmed:true gate, that batch edits are bounded, and that results report partial failures rather than a blanket success. It does not quantify the batch bound or describe 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?

The verbs are front-loaded in the first sentence, and the follow-on sentences each carry a distinct operational fact (opt-out sending, delete confirmation, batch result semantics). It is dense but every sentence earns its place, with only mild verbosity in the account-assignment 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?

For a multiplexed write tool with a rich anyOf schema and an output schema, the description supplies the missing operational context: per-mode behavior, delete confirmation, batch bounding, and partial-failure reporting. Return-value detail is correctly left to the output schema, so coverage is largely complete.

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

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

Schema coverage is around 50% and the description mostly restates schema-level semantics for sendAccountIds (omit/[] to avoid contacting engagers) rather than adding new meaning. It does not clarify the mode enum values or the workspaceId resolution behavior from a description standpoint, so it only partially compensates 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?

The description names the resource (competitor watches) and enumerates the specific operations the tool performs: create, pause/resume, assign observing LinkedIn accounts, and delete. It also differentiates from the sibling by noting that delete runs the same removal as campaignstack_delete_competitor_watch, so an agent can place the tool without opening either schema.

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

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

It gives clear situational context for each mode and explicitly routes the delete case via a named sibling plus a required confirmed:true precondition. It stops short of stating when NOT to use this tool (e.g. versus get_competitor_watches for reads), so it is clear but not exhaustive.

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

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

With annotations present (readOnly=false, destructive=false, idempotent=false), the description still adds real context: generators create drafts only, state transitions are validated and return per-operation results, and nothing is published. It omits idempotency/retry semantics despite idempotentHint=false and does not explain clientOperationId's role.

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 operation verbs, then generator behavior, then scope limits. No filler; each sentence adds distinct information.

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

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

For a multi-op mutation tool with an output schema (returns need not be described), the description covers the operation space, generator semantics, and the no-publish guarantee. Gaps remain around batch/error behavior and idempotency handling, which an agent invoking 25-item operation arrays would benefit from knowing.

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 50% schema coverage the description must compensate, and it does for the highest-value field: it explains the behavioral difference between generator.type=lead_magnet and generator.type=search_console_demand, which the schema only declares as consts. It does not clarify reason, scheduledAt, autoSchedule, or clientOperationId.

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 and complete verb set ('Create, update, duplicate (copyFromId), or request legal desired-state transitions for content'), naming both the resource and each operation. It is readily distinguishable from siblings like campaignstack_delete_content and campaignstack_get_content, and it explicitly bounds scope with 'nothing is published by this tool.'

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 context is clear: generator.type values are enumerated with what each drafts from, and it states that generators produce draft posts only while scheduling/approval/reject/retry are validated transitions. There is no explicit naming of alternative sibling tools or a 'use X instead' clause, so it stops short of a 5.

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

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

Annotations already declare 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 by describing state-preservation semantics for each case: a review-pending draft stays pending, a scheduled message keeps its slot and goes out without re-review, a job application keeps its status. It also notes the side effect that workflow edits feed durable writing preferences, and it is consistent with destructiveHint=false and idempotentHint=false.

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

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

Front-loaded with the core action and the key constraint, then the when-to-use, then state semantics, then the exclusion. Dense but every sentence carries information; the parenthetical about approval being 'recorded as an edit of the model's draft' is slightly heavy but still informative.

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 covers return values, and for a mutation tool with a nested updatedContent object the description supplies the necessary behavioral context (state preservation, no approval/send, scheduled-slot behavior). Nothing an agent needs in order 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 description coverage is 80%, so the schema already explains kind, confirmed, workspaceId, and updatedContent. The description's overlap ('revise a draft', 'scheduled message keeps its slot') reinforces intent but adds little parameter-level meaning beyond what the schema documents. 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?

Opens with a specific verb+resource+constraint: 'Save new words on one draft without changing its approval state.' It explicitly contrasts itself with campaignstack_decide_review ('It never approves, rejects or sends'), so an agent can separate it from the sibling that handles review decisions.

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

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

Gives explicit trigger 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 names the alternative tool for the approval path. Both when-to-use and when-not are 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?

Beyond the annotations it discloses the policy hierarchy (level-0 workspace vs additive level-1 child), the side effect that blocking stops running workflows from drafting to or contacting that person, and the partial-failure reporting contract ('report partial failures instead of describing the whole batch as successful'). These are semantic traits 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?

Front-loaded with the verb and resource, then triggers, then the alternative path, then constraints. Mostly dense and earnable, though 'Batch edits are bounded' is vague and largely restates the schema's maxItems/minItems limits.

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?

A five-mode, nested-object mutation tool with an output schema, and the description covers the highest-risk semantics (target hierarchy, partial failures, workspace fallback). Minor gaps remain around replace_child_exclusions and the meaning of exclusion state/config, but the essentials for correct invocation are present.

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

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

Schema coverage is 67% and the description adds real meaning: target type semantics, the effect of omitting exclusionId (workspace block list created on first use), and the additive constraint on child ids. It does not explain the replace_child_exclusions mode or the opaque state/config fields, leaving one operation under-described.

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 ('Edit exclusion policy') plus the three target scopes it operates on (workspace, signal agent, workflow), which separates it cleanly from the read-only sibling campaignstack_get_exclusions. It also carves out the add_manual_profiles path so the agent knows which behavior lives where.

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

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

Gives explicit invocation triggers ('when the user asks to add/remove blocked profiles, change filter rules, or enable/disable exclusion rules') and names the alternate route for the block-a-profile case, including the condition for omitting exclusionId. The boundary between workspace-level and child-level policy is stated as a hard rule ('additive only... cannot release workspace restrictions').

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/non-destructive/non-idempotent profile, and the description adds genuinely new behavior: 'full core/overlays replace the stored object' discloses replacement (not merge) semantics, and 'Restores are versioned' explains that reverting is version-tracked. Missing auth/permission requirements keep it from a 5.

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

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

A single dense sentence that is front-loaded with the purpose and packs identity resolution plus replacement/versioning semantics without filler. The semicolon-clause structure is a little cramped but every clause carries information.

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

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

For a 10-parameter mutation tool with nested core/overlays and low schema coverage, the description covers identity resolution and replace/restore behavior but omits the meaning of 'active', 'readableSummary', and the restore-version flow. An output schema exists, so return values need not be described, but input-side gaps remain.

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

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

Schema description coverage is only 20% (only workspaceId and linkedinAccountId documented), so the description must compensate. It usefully clarifies the identity-resolution trio and the replace semantics of core/overlays, but leaves 'active', 'readableSummary', and 'restoreVoiceVersionId' unexplained, so compensation is partial and the 3 baseline applies.

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

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

States a specific verb and resource ('Edit or restore one identity voice profile language'), so the agent knows it mutates and can restore a voice profile. However it does not explicitly distinguish itself from sibling campaignstack_refresh_identity_voice, which an agent could otherwise confuse with the restore path.

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 implicit when-to-use guidance by explaining how to target the identity (provide identityId, linkedinAccountId, googleAccountId, or none when the workspace has only one LinkedIn account). It stops short of naming alternatives or stating exclusions relative to refresh_identity_voice or get_identities.

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

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

Annotations only declare the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false). The description goes beyond by disclosing mutation semantics — queries replacement vs applicationProfile merge so prior answers persist, the account-usability gate on resume, and a confirmation requirement before automatic/applyEnabled calls. It omits return/error behavior, but an output schema exists.

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

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

Single dense paragraph, front-loaded with the four operations before branching into per-op detail and the confirmation caveat. Every sentence carries information, though it is on the long side.

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 tool with nested anyOf operations, 50% schema coverage, and an output schema, the description covers the behavioral essentials an agent needs (op semantics, merge/replace behavior, confirmation gate). Remaining gaps like workspaceId disambiguation are handled by the schema.

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

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

Schema coverage is only 50%, so the description must compensate. It does add meaning for queries (full replacement) and applicationProfile (merge semantics), plus the outboundMode/applyEnabled gating, but these largely restate schema text, and it says nothing about watcherId, clientOperationId, or workspaceId. Baseline 3 for partial compensation.

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

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

States specific verbs (create, update, pause, resume) against a specific resource (job watchers), and clarifies the name's ambiguity by noting it also creates. An agent can distinguish this from get_job_watchers (read) and archive_job_watcher (archive) 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?

Each operation is given its operational context (create binds to an account; pause stops new searches/applications; resume restarts if the account is usable), which tells the agent when each branch applies. It stops short of naming sibling alternatives (e.g. archive_job_watcher) or explicit when-not conditions.

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

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

Annotations already 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 only give coarse hints (destructive, not idempotent, not read-only). The description adds real behavioral context: archived status performs the same permanent removal as delete and needs confirmed:true, actAccountIds [] means collect without contacting, batch edits are bounded, and per-item results with partial-failure reporting rather than claiming whole-batch success.

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 list, then defaults and constraints; nearly every sentence carries actionable content such as confirmed:true, batch bounding, and partial-failure reporting. It is dense and somewhat long, with a little overlap against the schema's approvalMode text, 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?

Given an output schema exists, return values need not be explained, yet the description still notes one result per requested item and partial-failure reporting. Combined with defaults, deletion safety, and admin-only restrictions, an agent has everything needed to invoke the batch correctly.

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

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

The description adds the account-defaulting rule (omitted accountIds/actAccountIds fall back to the workspace's only ready LinkedIn account, otherwise an error listing them) and the read-vs-act account distinction. However, much of this is already restated in the schema's own field descriptions, so the marginal lift over the schema is moderate rather than large.

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 and resources (create/update/pause/restore signal agents, replace exclusions) and enumerates the operations the batch tool supports. It explicitly distinguishes itself from campaignstack_delete_signal_agent (archiving behaves the same) and campaignstack_get_signal_agents (source of versionId/history), 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?

Gives explicit when-to-use guidance: on create with multiple accounts, ask the person which accounts read vs. act; set approvalMode automatic only when the user asked for unreviewed messages; restore_guidance requires a versionId from campaignstack_get_signal_agents include.guidanceHistory. It also names alternatives and the conditions that select them.

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 mutability profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), reducing the description's burden. The description adds the useful behavioral note that each operation returns independently, but does not add much else beyond annotations, such as permission requirements, rate limits, or irreversible effects.

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

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

The description is front-loaded with the tool's operations and includes the key sibling routing directly afterward. The first sentence is a long enumerated list, which is dense but earns its place by covering the tool's full scope without filler.

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

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

Given the high-complexity batch schema and the presence of an output schema, the description is largely complete: it names all operation families, routes graph edits to the sibling, and explains the restore version source. It omits details like batch bounds, partial-failure semantics, and workspace scoping, but those are supplied by the schema and output schema.

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

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

With 100% schema description coverage, the baseline is 3, but the description adds meaning by naming several operations and clarifying that restore_guidance takes a versionId sourced from campaignstack_get_workflows include.guidanceHistory. It also translates some schema fields into plain language, such as email sender account and workflow-level outreach intents.

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 resource (workflow) and enumerates the exact operation types it supports, including create, metadata edits, approval mode, execution state, LinkedIn account pools, email sender, outreach intents, and guidance restore. It also explicitly distinguishes itself from campaignstack_edit_workflow_graph, so an agent can separate the two 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?

It gives a clear routing rule for graph changes, directing them to campaignstack_edit_workflow_graph, and notes that restore_guidance needs a versionId from campaignstack_get_workflows include.guidanceHistory. However, it does not provide broader when-to-use or when-not guidance for the many other operation types relative to other workflow tools.

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

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

Discloses behavior well beyond the annotations: atomicity, validation-before-persistence, config merge with null-clears-key semantics, edge replacement rules, and post-write split-node optimization. The one tension is that 'replace' discards the existing graph while destructiveHint=false, though the tool does not destroy the workflow itself, so this is a scoping nuance rather than a 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?

Five tight sentences, front-loaded with the core action and mode split, then merge semantics, then safety and optimization notes. Every sentence carries distinct information; nothing is redundant.

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

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

A mutation tool with a rich nested schema, an output schema, and annotations; the description covers mode behavior, merge semantics, validation, and the optional optimization pass. It lacks only preconditions (permissions, whether active workflows can be edited mid-run) which the description leaves to 'active-lead safety remains enforced by the workflow backend'.

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 does the heavy lifting: it explains mode semantics, the graph-vs-patch relationship, per-node config merging (only sent keys change, null clears), and when patch.edges replaces the edge set. workspaceId is left to the schema, which already documents it thoroughly.

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 or replace), resource (one workflow graph), and atomicity guarantee. This is clearly distinguished from the sibling campaignstack_edit_workflow, which edits the workflow itself rather than its graph structure.

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 precise operational guidance on choosing between the two modes: 'replace supplies the full non-anchor graph' vs 'patch starts from the current non-anchor graph'. It does not, however, state when to prefer one mode over the other or warn against calling this on an active 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?

Annotations already establish a non-destructive, non-read-only, non-idempotent write. The description adds real behavioral context beyond them: partial-update semantics ('Only supplied components change'), the blast radius of branding (client-facing shared artifacts only), what compliance toggles, and that restores are versioned. It omits permissions/auth requirements and reversibility details.

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

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

The operation list is front-loaded in the first sentence, followed by the partial-update rule and per-component effects, ending with the cross-tool instruction. Dense but every sentence carries information; minor compression is possible.

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-purpose mutation with an output schema present, the description covers operation scope, partial-update behavior, per-component effects, and prerequisites for the proposal decision. It is complete enough to call correctly, with only permission/reversibility details left unaddressed.

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 low (17%), but the nested schemas carry deep inline documentation (sections, companyProfile, outreachIntents). The description adds meaning by mapping components to effects (branding, compliance toggle, versioned restore, proposal decision) but supplies no syntax, format, or required-combination detail, so it only partially compensates.

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

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

The description enumerates the concrete operations (write settings, branding, compliance, restore a playbook version, accept/reject a proposal) on the workspace resource, so an agent knows exactly what it does. It implicitly distinguishes from siblings like edit_workspace_accounts or edit_workspace_members by limiting scope to settings/branding/compliance/playbook, though it does not name those siblings explicitly.

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

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

It gives a clear routing instruction for the proposal case: read the pending proposal via campaignstack_get_workspaces' playbookProposal include before deciding. It also states the optimistic-update rule ('Only supplied components change'). It lacks explicit when-not guidance for the settings/branding/compliance operations.

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.