campaignstack

campaignstack_preview_craft_prompt

Read-onlyIdempotent

Render the exact prompt a craft node would send for one lead, without sending it. Call this when the user asks to see what a draft would look like, or to debug why a node's wording keeps going wrong. Runs the real craft path and stops immediately before the model call, so what comes back is the same bytes the model would read. index lists the named blocks in the system prompt with their character offsets and sizes (COMPANY CONTEXT, WHAT WE WANT, the playbook sections, RED LINES, the voice), which is how you find out WHICH piece of configuration produces a phrase you do not want. Writes no audit row, records no AI usage, assigns no voice experiment arm, fetches no web context, and costs nothing. Pair it with campaignstack_get_craft_config_tree, which shows where each block comes from.

Input Schema

TableJSON Schema

Name	Required	Description
`leadId`	Yes	The lead to render the prompt for. Different leads produce different prompts.
`nodeId`	Yes	A craft node: ai:craft_note, ai:craft_message, ai:craft_comment, ai:reply_conversation, ai:craft_email, or a send node in its AI mode.
`include`	No	What to return. Default: index and user. The system prompt runs to thousands of characters, so ask for it when you are going to read it.
`leadSource`	No	Which lead table the id is in. Default: global.
`workflowId`	Yes	The workflow the node belongs to.
`workspaceId`	No	Workspace ID. REQUIRED for a user key (csu_), which spans every workspace you belong to; omitted for a workspace key (cs_), which is bound to one and ignores this argument. campaignstack_whoami reports which kind of key you are holding and, for a user key, the workspaces it can reach.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`chars`	No
`index`	No
`caller`	No
`nodeType`	No
`userPrompt`	No
`systemPrompt`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "caller": {
+      "anyOf": [
+        {
+          "anyOf": [
+            {
+              "not": {}
+            },
+            {
+              "type": "string"
+            }
+          ]
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "chars": {
+      "anyOf": [
+        {
+          "anyOf": [
+            {
+              "not": {}
+            },
+            {
+              "additionalProperties": true,
+              "properties": {
+                "systemPrompt": {
+                  "anyOf": [
+                    {
+                      "anyOf": [
+                        {
+                          "not": {}
+                        },
+                        {
+                          "type": "number"
+                        }
+                      ]
+                    },
+                    {
+                      "type": "null"
+                    }
+                  ]
+                },
+                "userPrompt": {
+                  "anyOf": [
+                    {
+                      "anyOf": [
+                        {
+                          "not": {}
+                        },
+                        {
+                          "type": "number"
+                        }
+                      ]
+                    },
+                    {
+                      "type": "null"
+                    }
+                  ]
+                }
+              },
+              "type": "object"
+            }
+          ]
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "index": {
+      "anyOf": [
+        {
+          "anyOf": [
+            {
+              "not": {}
+            },
+            {
+              "items": {},
+              "type": "array"
+            }
+          ]
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "nodeType": {
+      "anyOf": [
+        {
+          "anyOf": [
+            {
+              "not": {}
+            },
+            {
+              "type": "string"
+            }
+          ]
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "systemPrompt": {
+      "anyOf": [
+        {
+          "anyOf": [
+            {
+              "not": {}
+            },
+            {
+              "type": "string"
+            }
+          ]
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "userPrompt": {
+      "anyOf": [
+        {
+          "anyOf": [
+            {
+              "not": {}
+            },
+            {
+              "type": "string"
+            }
+          ]
+        },
+        {
+          "type": "null"
+        }
+      ]
+    }
+  },
+  "type": "object"
+}

AddedSep 13, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: it runs the real craft path and stops before the model call ('same bytes the model would read'), and enumerates side-effect non-occurrences ('Writes no audit row, records no AI usage, assigns no voice experiment arm, fetches no web context, and costs nothing'). No contradiction with annotations; this is exemplary full-burden disclosure.

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 purpose and when-to-use; dense but every sentence earns its place (behavioral guarantee, index semantics, side-effect clarity, sibling pointer). Slightly long with the multi-clause 'writes no... records no... assigns no... fetches no... costs nothing' enumeration, but that adds safety-relevant information rather than padding.

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?

Given an output schema exists (so return values need no description), rich annotations, and 100% parameter coverage, the description covers what's needed to call correctly: purpose, use cases, behavioral boundary, and default include behavior. The only minor gap is not spelling out the leadSource/workspaceId key nuance, but that's fully in the schema. Essentially complete.

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 100% so baseline is 3, but the description adds genuine value for the include parameter by explaining what 'index' returns — the named blocks with character offsets and sizes 'which is how you find out WHICH piece of configuration produces a phrase you do not want' — and why system is excluded by default (thousands of characters). This clarifies decision-making that the bare enum list does not.

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?

Opens with a specific verb+resource+constraint: 'Render the exact prompt a craft node would send for one lead, without sending it.' This immediately distinguishes it from the craft_* siblings that actually send, and from explain_draft/preview-like alternatives. The purpose is unambiguous.

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?

Gives explicit when-to-use triggers: 'when the user asks to see what a draft would look like, or to debug why a node's wording keeps going wrong.' It names a complementary sibling (campaignstack_get_craft_config_tree) for tracing block provenance. It does not explicitly phrase a when-not-to-use, though 'without sending it' and preview framing imply the send case belongs to the craft_* tools.

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

All campaignstack 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.

Resources

Need Help?