TechFabric

Change a published post

revise_post

Idempotent

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). Open a revision of a post that is live on techfabric.com, by its URL or slug: only its author or the blog's editor. The revision's draft starts as the live text, with its own preview; then the same loop: get_status for its markdown, lint_draft with the id and your edit, update_draft, check_draft with the id, publish_draft. Publishing replaces the post at the same URL and byline and keeps its date. Asking again returns the revision already open.

Input Schema

Name	Required	Description	Default
`post`	Yes	The live post to change: its URL (https://www.techfabric.com/blog/<slug>) or its slug

Output Schema

Name	Required	Description
`id`	Yes	The revision's draft id
`next`	Yes
`slug`	No
`state`	Yes
`byline`	No
`meaning`	No
`live_url`	Yes
`duplicate`	No
`editor_link`	No
`next_action`	Yes	The one next step. Do what instruction says; call is the tool and the arguments the server already knows
`preview_url`	No
`revision_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 22, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "properties": {
+    "byline": {
+      "type": "string"
+    },
+    "duplicate": {
+      "type": "boolean"
+    },
+    "editor_link": {
+      "type": "null"
+    },
+    "id": {
+      "description": "The revision's draft id",
+      "type": "string"
+    },
+    "live_url": {
+      "type": "string"
+    },
+    "meaning": {
+      "type": "string"
+    },
+    "next": {
+      "type": "string"
+    },
+    "next_action": {
+      "description": "The one next step. Do what instruction says; call is the tool and the arguments the server already knows",
+      "properties": {
+        "action": {
+          "enum": [
+            "interview",
+            "outline",
+            "approve",
+            "lint",
+            "rewrite",
+            "save",
+            "submit",
+            "verify",
+            "wait",
+            "answer",
+            "confirm",
+            "publish",
+            "report",
+            "done",
+            "stop"
+          ],
+          "type": "string"
+        },
+        "call": {
+          "properties": {
+            "arguments": {
+              "type": "object"
+            },
+            "tool": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "tool",
+            "arguments"
+          ],
+          "type": "object"
+        },
+        "instruction": {
+          "type": "string"
+        },
+        "rounds": {
+          "properties": {
+            "max": {
+              "type": "integer"
+            },
+            "round": {
+              "type": "integer"
+            }
+          },
+          "required": [
+            "round",
+            "max"
+          ],
+          "type": "object"
+        }
+      },
+      "required": [
+        "action",
+        "rounds",
+        "instruction"
+      ],
+      "type": "object"
+    },
+    "preview_url": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "revision_id": {
+      "type": "string"
+    },
+    "slug": {
+      "type": "string"
+    },
+    "state": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "state",
+    "live_url",
+    "next_action",
+    "next"
+  ],
+  "type": "object"
+}

AddedOct 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With annotations already declaring idempotentHint and destructiveHint, the description still adds substantial context: the auth scope, the author/editor-only restriction, that the revision's draft is seeded from the live text with its own preview, that publishing replaces the post at the same URL and byline while keeping the date, and that repeated calls return the already-open revision. That last point corroborates idempotency with concrete behavior rather than contradicting it.

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 prerequisite and then walks the loop in order, with almost no wasted words. It is telegraphic in places ('then the same loop') and leans on prior knowledge of the sibling workflow, which slightly reduces standalone clarity.

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, so return values need not be explained; the description covers prerequisites, permissions, side effects (same URL/byline, preserved date), and the downstream tool chain. Nothing material is missing for correct invocation.

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 coverage is 100% for the single 'post' parameter, so the baseline is 3. The description adds real semantics beyond the schema: the target must be a *live* post (not a draft), and it restates the URL-or-slug freedom of the parameter.

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: 'Open a revision of a post that is live on techfabric.com, by its URL or slug'. The 'live post' qualifier distinguishes it from start_post (new draft) and update_draft (edit a draft), so an agent can route correctly without opening a schema.

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

Usage Guidelines4/5

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

Gives clear preconditions (Microsoft sign-in with blog.write scope, caller must be the post's author or the blog editor) and spells out the follow-on loop: get_status, lint_draft, update_draft, check_draft, publish_draft. It does not explicitly state when *not* to use it (e.g. drafts vs. live posts named as a sibling alternative), so it stops short of a 5.

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

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