Mark

Send CMS Preview

send_cms_preview

Saves a blog, FAQ or competitor post that is not yet approved (draft, changes requested, or in review) to its website CMS as a draft, so a reviewer can open it on the customer's own site before approving. Sends the post's current saved content. Always a draft, even when the connection publishes live, and nothing goes live. Sending again updates the same CMS document; approving later updates it too. Refused, with the reason, for an approved, scheduled or published post, a channel with no CMS mapping, or a collection without drafts. Refused as a conflict when the CMS page changed since Mark last sent it; choose overwrite or keep with resolve_cms_conflict. Refused when another page in the CMS uses the post's slug: the error names each page (CMS id, title, its latest draft when it differs, live or draft, edit link, and the Mark post that owns it, if any) and says which ids useCmsPageId accepts. Then either change the slug with save_post, or call again with useCmsPageId to send into that page. Does not approve or change the post's status. Related: get_post (website.previewUrl, previewSentAt), save_post, approve_posts.

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": {
      "postId": "<postId>"
    },
    "name": "send_cms_preview"
  }
}

Input Schema

Name	Required	Description	Default
`postId`	Yes	The website post to preview.
`useCmsPageId`	No	Send into this existing CMS page instead: a page id a refusal listed as one useCmsPageId accepts (not live, and no other Mark post owns it). Replaces that page's content with this post. It stays a draft, and from then on it is this post's page.

Output Schema

Name	Required	Description	Default
`state`	Yes
`sentAt`	Yes
`previewUrl`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026
- changedInput schema / properties / useCmsPageId / pattern
```
Previous value: -"^[\\w-]{1,128}$"New value: +"^[\\w:-]{1,128}$"
```

Changed1 schema field changedOct 15, 2026

addedInput schema / properties / useCmsPageId

Added value: +{
+  "description": "Send into this existing CMS page instead: a page id a refusal listed as one useCmsPageId accepts (not live, and no other Mark post owns it). Replaces that page's content with this post. It stays a draft, and from then on it is this post's page.",
+  "pattern": "^[\\w-]{1,128}$",
+  "type": "string"
+}

AddedOct 14, 2026

TDQS

A4/5.0

Behavior1/5

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

The description richly discloses draft-only behavior, that nothing goes live, repeated-send behavior, refusal reasons, conflict handling, and that it does not approve or change status. However, annotations declare destructiveHint=false while the useCmsPageId parameter explicitly says it 'Replaces that page's content with this post'—a destructive update to an existing CMS page. That contradicts the annotation, so this is scored 1 per the rubric.

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 main action and draft-only scope are front-loaded, and most sentences serve refusal or conflict handling. It is somewhat long because of the detailed slug-collision error explanation, but that detail is operationally relevant.

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

Completeness5/5

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

Covers eligibility, draft-only behavior, refusal cases, conflict resolution, slug-collision handling, status effects, and related tools. Since an output schema exists, the description need not explain return values.

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 description coverage is 100%, so the baseline is 3. The main description adds useful meaning beyond the schema by constraining postId to posts that are not yet approved and explaining the useCmsPageId workflow after a slug-collision refusal.

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 and resource: saving an unapproved blog, FAQ, or competitor post to its website CMS as a draft for reviewer preview. It clearly distinguishes this from approval/publishing and names related tools, so an agent can select it confidently.

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

Usage Guidelines5/5

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

Explicitly defines when to use it (draft, changes requested, or in review), when it is refused (approved, scheduled, published, no CMS mapping, no drafts), and which alternatives or follow-up tools apply (resolve_cms_conflict, save_post, useCmsPageId).

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

All Mark 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?