Skip to main content
Glama
Sign In

seodraft

by app.seodraft
OverviewDiscussionsAdmin

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. On a git destination, an article already marked published (from the seodraft app or by hand) refuses with degraded reason published, because a draft file would take the live article offline. 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

NameRequiredDescriptionDefault
idYes
workspaceIdNoThe 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.

  1. Changed1 schema field changed
    • 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"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes far beyond annotations: which fields are preserved on a Sanity patch, that draft: true is forced, that a published git article is refused as `published`, that repeat delivery overwrites the same path and is safe, and what happens to the old file when the slug changes. It also enumerates all degraded reasons (no-target, no-token, github-error, etc.). The 'never publishes / never deletes' statements are consistent with destructiveHint=true, since overwriting and patching are genuinely mutation-prone.

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-loads purpose and the approve_post contrast, then splits git vs Sanity behavior and returns cleanly. It is long and dense, and a few clauses (e.g. the repeated return-field recitals) could be trimmed, but nearly every sentence carries actionable behavior.

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?

There is no output schema, yet the description documents the return shape for both providers (path, commitSha, htmlUrl, documentId, studioUrl, updated, pendingImageSlots, degradations). For an open-world, mutating, provider-branching tool this covers everything an agent needs to call it and interpret the result.

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 documented, id not), and the description never mentions either parameter or the id-vs-workspace resolution. It does clarify what the target article must be (approved, ready), which adds some meaning worth having, but it does not compensate for the bare `id` field.

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') plus the two concrete destinations (git file, Sanity draft document). It explicitly contrasts with approve_post, so an agent can separate the retry path from the normal delivery path without opening either 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?

Explicitly says when to use it ('the retry and the re-send after an edit, not the normal path') and names the alternative that covers the normal case (approve_post). It also lists the preconditions (run_gate passed, article ready) and the refusal conditions with their degraded reasons.

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

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