seodraft

Re-deliver draft to CMS

deliver_draft

DestructiveIdempotent

Re-deliver one already approved article to the workspace's destination as a draft: a file in its git repository, or a draft document in its Sanity dataset. approve_post already delivers on approval, so this is the retry and the re-send after an edit, not the normal path. Requires the last run_gate check to have passed and the article to be ready (approve_post first); otherwise it refuses with degraded reason gate-failed or not-ready. It never publishes, never deletes and never removes the draft flag: publishing stays the human's. Git (provider github): the file is written with draft: true forced, whatever key the destination maps that to. Delivering the same article again overwrites the same path, so it is safe to repeat; if the slug changed since the last delivery the new path is written and previousPath names the old file, which is left in place for the human to delete. Returns path, commitSha, htmlUrl (the file on GitHub), commitUrl, updated (false on the first delivery) and pendingImageSlots: the pictures the article asked for and nobody uploaded, which the human adds in the CMS. Sanity (provider sanity): it creates or patches the draft drafts.seodraft-<id>; re-delivering patches only the fields seodraft maps, so an author, category or image set in Studio survives. Returns documentId, studioUrl (opens the draft in Studio), updated, pendingImageSlots and degradations: what the destination's Portable Text could not carry (kind image-skipped with the image URL, or converter with what was flattened), which the human fixes in Studio. Other degraded reasons: no-target (nothing configured in Profile -> Publishing), no-token, secrets-key-missing, github-error or sanity-error (with status and the CMS's own message).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`workspaceId`	No	The workspace this call acts on, as listed by list_workspaces. Left out, the call uses the workspace the account is in right now.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 2, 2026

addedInput schema / properties / workspaceId

Added value: +{
+  "description": "The workspace this call acts on, as listed by list_workspaces. Left out, the call uses the workspace the account is in right now.",
+  "type": "string"
+}

First observedSep 27, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare the safety profile (readOnly=false, idempotent=true, destructive=true, openWorld=true), but the description adds substantial behavior on top: it never publishes/deletes, forces draft:true in git, overwrites the same path on repeat, handles slug changes via previousPath, patches only seodraft fields in Sanity, and enumerates degraded reasons (no-target, no-token, secrets-key-missing, github-error, sanity-error). This is exactly the added context the annotations cannot convey.

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 key differentiator (retry vs normal path) and prerequisites, and every sentence carries behavioral or return-value information. It is nonetheless a dense single block of ~1500 characters; some return-field detail could be tightened, though with no output schema much of it is load-bearing.

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?

With no output schema and a mutation-style tool, the description carries the full burden and does so: it documents prerequisites, provider-specific behavior (github vs sanity), idempotency/overwrite semantics, returned fields (path, commitSha, htmlUrl, documentId, studioUrl, updated, pendingImageSlots), and the complete set of degraded reasons. An agent has everything needed to invoke it correctly.

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 coverage is 50%: workspaceId is documented in the schema but id has no schema description. The description only indirectly identifies the parameters ('one already approved article', 'the workspace's destination') without stating that id is the article identifier or clarifying workspaceId behavior, so it does not fully compensate for the undocumented id parameter. Baseline 3 is appropriate given partial schema coverage and only indirect param meaning in the description.

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 ('Re-deliver one already approved article ... as a draft') and explicitly positions itself against the sibling approve_post, calling itself 'the retry and the re-send after an edit, not the normal path'. An agent can distinguish it from approve_post and upsert_post without opening any schema.

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?

Gives explicit preconditions ('Requires the last run_gate check to have passed and the article to be ready (approve_post first)') and an explicit exclusion ('not the normal path'), plus the failure modes when the conditions are unmet (gate-failed, not-ready). Nothing about when to select this tool is left to inference.

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

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