preview_activate_campaign_linkedinDry-run: which accounts would get the campaign audience queued, how many contacts and what is already queued. Nothing changes. Call before activate_campaign_linkedin.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Campaign id (UUID) from list_campaigns | |
| account_ids | No | Default: settings.selectedLinkedinAccountIds, else all connected accounts |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well by stating 'Nothing changes' and framing the call as a dry-run, so the agent knows it has no side effects. It also discloses the preview output categories, though it does not mention permissions or error conditions.
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 clauses front-load the dry-run nature, follow with the no-change guarantee, and end with the sequencing instruction. Every sentence contributes information without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter preview tool with no output schema, the description gives enough context to call it correctly and understand what the result will cover. It could be more complete about preconditions or failure behavior, but the core preview contract is clear.
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 both the campaign id and the account_ids default behavior are already documented in the schema. The description adds no parameter-level details beyond the schema, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific dry-run operation and exactly what it reveals: affected accounts, contact counts, and already-queued state. It distinguishes the tool from the actual activation sibling by labeling itself a dry-run and naming activate_campaign_linkedin as the follow-up.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to call this before activate_campaign_linkedin, which gives clear sequencing guidance. It does not spell out when not to use it or name other preview siblings, but the intended usage is unambiguous for this workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.