Rankwise

Publish article

publish_article

Destructive

Publish one article to the workspace's connected CMS (WordPress, WordPress.com, Shopify, Webflow, Wix, Ghost, Notion, Framer or a self-hosted site). This makes it live on the customer's website. A brief draft must be approved by its expert first. If the workspace has several CMS connections and no default destination, name one with integration_id. Pass publish_at (an ISO date-time) to schedule it, or "next_slot" for the workspace's next publish time. To change an article that is already published, do not publish it again (on some sites that adds a second post): edit it with replace_article, then call update_live_post.

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": {
      "article_id": "<article_id>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "publish_article"
  }
}

Input Schema

Name	Required	Description	Default
`article_id`	Yes
`publish_at`	No
`integration_id`	No
`idempotency_key`	Yes

Output Schema

Name	Required	Description	Default
`job_id`	No
`next_step`	No
`article_id`	Yes
`scheduled_for`	No
`already_queued`	No
`integration_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

changedInput schema / properties / publish_at / anyOf

Previous value: -[
-  {
-    "const": "next_slot",
-    "type": "string"
-  },
-  {
-    "format": "date-time",
-    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
-    "type": "string"
-  }
-]New value: +[
+  {
+    "const": "next_slot",
+    "type": "string"
+  },
+  {
+    "format": "date-time",
+    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+    "type": "string"
+  }
+]

First observedOct 20, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true, openWorldHint=true and idempotentHint=false; the description corroborates the destructive/external nature and adds a concrete failure mode ('on some sites that adds a second post') plus the approval prerequisite. It does not explain the role of the required idempotency_key, which is the one behavioral safeguard an agent most needs to understand.

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 action and effect, then prerequisites, then parameter guidance, then the sibling routing rule — a sensible information order with little waste. The CMS enumeration is slightly long but usefully concrete.

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?

Output schema exists, so return values need no explanation, and the description covers preconditions, destination selection, scheduling, and the republish hazard for a destructive external write. The single gap is idempotency_key semantics, which matters given the tool's destructive, non-idempotent profile.

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 description coverage is 0%, so the description must carry parameter meaning, and it only partially does: it defines publish_at (ISO date-time or 'next_slot') and integration_id (when a named destination is needed). article_id is self-evident, but the required idempotency_key is never explained in either schema or description, leaving a mandatory parameter's semantics undocumented.

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 ('Publish one article') plus the exact external effect ('makes it live on the customer's website') and enumerates the supported CMS targets. It is clearly separable from siblings like replace_article and update_live_post, which the description explicitly contrasts against.

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 (draft must be approved by its expert), the condition for supplying integration_id ('several CMS connections and no default destination'), and the branching rule for scheduling via publish_at vs 'next_slot'. It also states a clear when-not: do not republish an already-live article, use replace_article then update_live_post instead.

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

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