Skip to main content
Glama

Mark

by com.use-mark.app
OverviewDiscussionsAdmin

Archive Post

archive_post
Idempotent

Takes a post out of the publish path so it will not go live. The post stays in the workspace; this is not a delete. Posts that are already live, queued to publish, or approved cannot be archived — they stay as they are. Archiving a post that is not a draft (in review, sent back, failed or missed) rejects it, so on a channel set to admins only (approverRole: approver) only workspace admins can archive it; drafts stay open to everyone. Calling it again on a post that will not publish is a no-op. Archiving a website post that sent a preview to its CMS deletes that preview draft when Mark may; otherwise cmsPreview says it is still in the CMS, where, and why, and so does the post's review note. Related: delete_post, review_post, search_posts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoOptional reason stored on the post.
postIdYesThe post to archive.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
postIdYes
statusYes
outcomeYes
cmsPreviewNoThe post's preview draft in the website CMS: removed (Mark deleted it), or left_in_cms with its previewUrl and why (cannot_delete: Mark's API key may not delete it; edited: changed in the CMS; linked: a page that was in the CMS before Mark used it; live: a live page; unreachable: the CMS did not answer). Absent when the post had no preview.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / cmsPreview
      Added value: +{
+  "description": "The post's preview draft in the website CMS: removed (Mark deleted it), or left_in_cms with its previewUrl and why (cannot_delete: Mark's API key may not delete it; edited: changed in the CMS; linked: a page that was in the CMS before Mark used it; live: a live page; unreachable: the CMS did not answer). Absent when the post had no preview.",
+  "oneOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "outcome": {
+          "const": "removed",
+          "type": "string"
+        }
+      },
+      "required": [
+        "outcome"
+      ],
+      "type": "object"
+    },
+    {
+      "additionalProperties": false,
+      "properties": {
+        "outcome": {
+          "const": "left_in_cms",
+          "type": "string"
+        },
+        "previewUrl": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "reason": {
+          "enum": [
+            "cannot_delete",
+            "edited",
+            "linked",
+            "live",
+            "unreachable"
+          ],
+          "type": "string"
+        }
+      },
+      "required": [
+        "outcome",
+        "previewUrl",
+        "reason"
+      ],
+      "type": "object"
+    }
+  ]
+}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description adds substantial context beyond them: the post is retained in the workspace, re-calling is a no-op, non-draft posts are rejected, and CMS preview drafts may be deleted as a side effect. Minor tension worth noting: it discloses a genuine deletion ('deletes that preview draft') while destructiveHint=false, though that applies to the primary resource, so it does not rise to a contradiction.

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 the core action and the not-a-delete distinction, then layers preconditions and edge cases. The length is defensible given the mutation semantics, permissions, and CMS interaction it must cover, though the CMS-preview sentence is dense and could be tightened.

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?

An output schema exists, yet the description still explains the cmsPreview/review-note failure path, which is the piece an agent most needs to interpret a partial outcome. Combined with permission rules, idempotency, and preconditions, nothing needed to invoke it correctly is missing.

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 100% with only two parameters, so the schema already carries the full parameter burden. The description adds a little meaning by referencing the post's 'review note' and the cmsPreview output field, but gives no additional syntax or constraint for note or postId beyond the schema text. Baseline 3 applies.

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 ('Takes a post out of the publish path') and immediately disambiguates from the most confusable sibling by saying 'this is not a delete.' The named related tools (delete_post, review_post, search_posts) let an agent place it in the toolset 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?

Explicitly enumerates when the tool will NOT act ('already live, queued to publish, or approved cannot be archived'), states the permission precondition for restricted channels (approverRole: approver), and names alternatives. This is as close to a decision rule as a description gets.

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

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