Skip to main content
Glama
Moe03

Convocore MCP Server

by Moe03

campaigns_write

Destructive

Create, update, delete, start, stop, or restart outbound call campaigns, including resume dialing or reset conversations.

Instructions

Create, edit, delete, start/stop or restart an outbound call campaign. Actions: create (campaign needs name + leadGroupName; created stopped unless enabled is true), update (partial: send only the fields to change in campaign), delete, enable (START dialing — places real phone calls to the lead group; resumes where it stopped), disable (stop), restart (start again from the first lead; resetConversations=true also clears earlier call conversations). Campaign fields: name, leadGroupName (a lead group name, or "all"), delayBetweenEachCall (seconds), concurrentSlots, initialPrompt, overrideInitialPrompt, postCallPrompt, postCallMetrics (custom metric ids), openTime / closeTime ("HH:mm" 24h), openDays (monday…sunday), timezone (IANA). The agent needs an assigned phone number before a campaign can start.

Input Schema

NameRequiredDescriptionDefault
modeNocompact (default) = light mode: long text is cut and bulky blobs are replaced by a size marker. full = complete API response.
actionYes
agentIdYes
campaignNoFor create / update. name, leadGroupName (a lead group name, or "all"), delayBetweenEachCall (seconds), concurrentSlots, initialPrompt, overrideInitialPrompt, postCallPrompt, postCallMetrics (custom metric ids), openTime / closeTime ("HH:mm" 24h), openDays (monday…sunday), timezone (IANA).
campaignIdNoRequired for every action except create.
resetConversationsNoFor restart. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.6.17

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, openWorldHint=true and non-idempotent, but the description adds material context those annotations cannot convey: that 'enable' dials real phone numbers, that restart resets to the first lead, that resetConversations=true erases earlier call conversations, and that newly created campaigns are stopped by default. That is exactly the kind of side-effect disclosure an agent needs before invoking 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.

Conciseness4/5

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

The most decision-relevant information (action list and per-action behavior) is front-loaded in the opening sentence, and the compact parenthetical style keeps a lot of detail dense. Minor waste comes from restating the campaign field list that already exists verbatim in the input schema.

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

Completeness4/5

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

For a destructive, nested-object, six-parameter tool with no output schema, the description covers actions, prerequisites and side effects well. It does not mention the 'mode' parameter's compact/full output behavior or say anything about what the call returns, which leaves a small but real gap given there is no output schema.

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

Parameters4/5

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

Schema coverage is 67%, and the description explains the semantics of every action enum value plus resetConversations and the campaign field set (including non-obvious values like leadGroupName='all' and HH:mm formats). It does add meaning beyond the schema, though the campaign field list is largely duplicated from the schema's own campaign description rather than extended.

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 set of verbs (create, edit, delete, start/stop, restart) operating on a precisely named resource (outbound call campaign). An agent can immediately distinguish this from campaigns_read, which is the read-only sibling.

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

Usage Guidelines4/5

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

Each action is given its own operational semantics: create requires name + leadGroupName and starts stopped unless enabled=true; update is partial; enable places real calls and resumes from where it stopped; restart begins from the first lead. It also states the prerequisite that the agent needs an assigned phone number before starting. The only gap is that it never explicitly routes the agent to campaigns_read for listing/reading.

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