Prosp MCP Server

Create Campaign

create_campaign

Create a paused LinkedIn outreach campaign from a node sequence, using actions, conditions, delays, and tags to structure connection requests, messages, and follow-ups.

Instructions

Create a campaign from a node sequence. Starts paused.

NODES. Each node is {"action": ..., "delay_days": ..., "config": {...}} or {"condition": ..., "yes": [...], "no": [...]}.

Available actions: connection_request, message, voice_note, inmail, open_profile_message, comment_last_post, reply_comment, like_last_post, visit_profile, wait, add_tag.

Available conditions: has_linkedin_url, is_first_level, opened_message, is_open_profile, check_column.

THE STANDARD SHAPE: 1 Condition: is_first_level 2 YES branch: message 3 NO branch: connection_request, then message on acceptance 4 Wait 3 days, follow-up on a different angle 5 add_tag

TWO RULES THE BUILDER WILL NOT ENFORCE FOR YOU:

No wait node after a connection_request. Acceptance auto-detects over two weeks, checking every 24 hours with a random delay. A wait node there does nothing except delay the sequence by days, and it is the most common unnecessary node people add.

Four touches maximum. After that the answer is no, and a fifth touch costs more in reputation than it returns in replies.

The daily limits default deliberately low. A new account should start at 10 connection requests a day and build to 20 over a fortnight, because a profile with no sending history suddenly running at full rate is the clearest possible pattern.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes
`nodes`	Yes
`confirm`	No
`list_id`	Yes
`account_id`	Yes
`daily_message_limit`	No
`daily_connection_limit`	No
`skip_leads_in_other_campaigns`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 30, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it discloses the safe default ('Starts paused'), that the builder enforces no rules around wait nodes or touch limits, and that daily limits default low. It omits other behavioral facts an agent would want, such as what the 'confirm' flag does or whether creation requires a verified account.

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

Conciseness4/5

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

Long but well-structured with clear headers (NODES, THE STANDARD SHAPE, TWO RULES) and front-loaded purpose. Most content earns its place, though the ramp-up rationale in the final section is somewhat more verbose than needed to convey the default.

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

Completeness3/5

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 needn't be explained. However, for a complex mutation tool with 8 params and 0% schema coverage, the description leaves several required-adjacent params (account_id, list_id, confirm, skip_leads) undocumented, making it adequate but not fully complete.

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

Parameters3/5

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

With 0% schema description coverage, the description must compensate. It richly documents the 'nodes' structure (actions, conditions, branch shape) and touches on daily limits, but leaves account_id, list_id, name, confirm, and skip_leads_in_other_campaigns entirely unaddressed. Partial compensation only.

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

Purpose5/5

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

States a specific verb+resource ('Create a campaign') and immediately adds scope that separates it from siblings: built 'from a node sequence' and 'Starts paused'. An agent can distinguish it from list_campaigns, get_campaign, set_campaign_status, and diagnose_campaign 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.

Usage Guidelines3/5

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

The description gives detailed guidance on HOW to build a campaign (standard shape, no-wait-after-connection_request, four-touch cap, ramp-up limits), but never states WHEN to choose this tool over alternatives or any prerequisite conditions. Usage is implied by the construction rules rather than routed explicitly.

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