Skip to main content
Glama
Sign In
slidecold-mcp

slidecold-mcp

by slidecold
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create a campaign

create_campaign

Create a draft Instagram cold-DM campaign with templates, follow-ups, sender accounts, and audiences; automatically add a pending recipient for each deduplicated audience member.

Instructions

Create a campaign. Required API key scope: campaigns:write. POST /campaigns Creates a DRAFT campaign with templates, follow-ups, accounts and audiences, and creates a PENDING recipient for every (deduplicated) member of the given audiences. timezone is accepted but ignored: the user's account timezone is used. Validation errors are reported as "<field>: <message>".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "body": "<body>"
    },
    "name": "create_campaign"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyYesJSON request body.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.6/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that the campaign is created in DRAFT (not sent), that a PENDING recipient is materialized for every deduplicated audience member, that `timezone` is silently ignored, that the `campaigns:write` scope is required, and the exact validation error string format. These are precisely the surprises an agent must plan around before a non-idempotent write.

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?

Front-loaded with the verb, then scope, then method/path, then side effects and quirks; every clause carries information. The 'POST /campaigns' line is near-redundant for an agent, which is the only wasted element.

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?

Given a single nested body param and no output schema, the create-side semantics are well covered, but the description never indicates what is returned (campaign id? full object?) so the agent cannot chain a subsequent get_campaign or update_campaign reliably. Idempotency implications of duplicate creates are also left implicit.

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?

Schema description coverage is already 100%, so the schema baseline applies; the description adds only the meaningful extra semantics of audience deduplication and the ignored timezone, both of which are largely restated from the schema's own field descriptions. Nested template/followup/weight/dailyLimit parameters get no additional meaning.

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

Purpose4/5

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

The description opens with a specific verb and resource ('Create a campaign') and adds the concrete material being composed (templates, follow-ups, accounts, audiences). It does not explicitly contrast with siblings like update_campaign, but the create/update distinction is obvious from the verb.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites beyond the API key scope, and no mention of alternatives (e.g., create then update_campaign, or retry_campaign for existing campaigns). The agent must infer that this is the entry point for new outreach.

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

Deploy Server

Other Tools