FavCRM

create_campaign

Create an email, SMS, WhatsApp, or push campaign in DRAFT. audienceExclusions can omit specific account IDs and recipients of previous campaign IDs. For email channelConfig, use subject + htmlBody + optional plainTextBody. recipientSource="list" is accepted as an alias for "individual".

Input Schema

Name	Required	Description
`name`	Yes	Campaign name (internal)
`status`	No	Default DRAFT
`channel`	Yes	email \| sms \| whatsapp \| push
`segmentId`	No	Required if recipientSource="segment"
`scheduledAt`	No	ISO datetime for scheduled send (status must be SCHEDULED)
`recipientIds`	No	Required if recipientSource="individual", "list", or "csv"; values are account IDs
`channelConfig`	No	Channel-specific config: subject + htmlBody + optional plainTextBody for email; body for sms; approved templateId plus required bodyParameters, headerTextParameter, or headerMediaUrl and optional whatsappConnectionId for whatsapp. Legacy email html is normalized to htmlBody.
`recipientSource`	No	Where to source recipients from. "list" is normalized to "individual".
`audienceExclusions`	No	Optional exclusions: accountIds contains specific customer account IDs; campaignIds contains previous campaign IDs whose accepted recipients must be omitted. A recipient matching any rule is excluded.

Output Schema

Name	Required	Description
`data`	Yes	Tool result payload — shape varies per tool, see the tool description
`summary`	Yes	One-line human-readable summary of the action
`renderType`	Yes	UI rendering hint for the result

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 16, 2026

changedInput schema / properties / channelConfig / description

Previous value: -"Channel-specific config: subject + htmlBody for email, body for sms/whatsapp, templateId, etc. Legacy email html is normalized to htmlBody."New value: +"Channel-specific config: subject + htmlBody + optional plainTextBody for email; body for sms; approved templateId plus required bodyParameters, headerTextParameter, or headerMediaUrl and optional whatsappConnectionId for whatsapp. Legacy email html is normalized to htmlBody."

Changed1 schema field changedSep 3, 2026

addedInput schema / properties / audienceExclusions

Added value: +{
+  "description": "Optional exclusions: accountIds contains specific customer account IDs; campaignIds contains previous campaign IDs whose accepted recipients must be omitted. A recipient matching any rule is excluded.",
+  "properties": {
+    "accountIds": {
+      "default": [],
+      "items": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "maxItems": 1000,
+      "type": "array"
+    },
+    "campaignIds": {
+      "default": [],
+      "items": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "maxItems": 50,
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

First observedJun 8, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare the write/mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower. The description adds useful normalization behavior (list accepted as an alias for individual) and exclusion semantics, but does not disclose auth/permission requirements, whether the created campaign is validated, or any failure modes.

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

Conciseness5/5

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

Four tight sentences with zero filler, front-loaded with the core create action before the conditional details on exclusions and channelConfig. Every sentence carries distinct, actionable information.

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?

With an output schema present, return values need no explanation, and the description covers the non-obvious parts (exclusions, per-channel config, alias). It is nearly complete for a 9-parameter nested tool; only the relationship between channel and required channelConfig keys could be tighter.

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 100%, so the baseline is 3. Most of the description's parameter detail (email subject+htmlBody, list alias, exclusion behavior) is already resident in the schema, so it adds only marginal meaning beyond structured fields rather than compensating for gaps.

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 (Create) plus resource (campaign), and enumerates the supported channels while pinning the initial state to DRAFT. An agent can immediately distinguish it from update_campaign, validate_campaign, clone, and delete_campaign without consulting schemas.

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?

Usage is implied (create a new campaign when you need one) but no when-not-to-use or alternative routing is given; validate_campaign and preview_segment_count are never mentioned despite being obvious prerequisites/preview steps. The alias and channelConfig hints are invocation help rather than selection guidance.

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

All FavCRM tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.