TechFabric

Review before publishing

review_before_publishing

Read-onlyIdempotent

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). A read: whether one of your drafts may be published now, and if so the question to ask the engineer ("Publish '' now? (yes/no)") with a one-time confirmation for this exact saved text and its checks (used once). Only after they say yes, call publish_draft with the id and that confirmation, and the same override. If it can't be published yet, it says why and what to do.

Input Schema

Name	Required	Description	Default
`id`	Yes	The idea id of your own draft
`override`	No	Publish anyway: the failing check ids the engineer chooses to publish past (only wording and style checks). Send the same list to publish_draft with the confirmation

Output Schema

Name	Required	Description
`id`	Yes
`run`	No
`url`	No	Where it goes live
`next`	Yes
`title`	No
`status`	Yes
`details`	No	Where and under whose byline it goes live: show it beside the question if they ask
`reasked`	No	True when the confirmation sent no longer fitted (it lapsed, or the text or its checks moved): ask this fresh question instead, plainly
`question`	No	What to ask the engineer, word for word: "Publish '<title>' now? (yes/no)", then anything else they are agreeing to
`text_hash`	No
`overridden`	No
`next_action`	No	The one next step. Do what instruction says; call is the tool and the arguments the server already knows
`preview_url`	No
`waiting_for`	No	card: a client that shows the draft card publishes only on the engineer's Publish there; nothing to send back
`confirmation`	No	One-time: send it back to publish_draft only after the engineer says yes. Never show it to them
`confirmed_by`	No
`expires_in_seconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

addedOutput schema / properties / waiting_for

Added value: +{
+  "description": "card: a client that shows the draft card publishes only on the engineer's Publish there; nothing to send back",
+  "enum": [
+    "card"
+  ],
+  "type": "string"
+}

Changed4 schema fields changedOct 23, 2026

changedOutput schema / properties / confirmation / description

Previous value: -"One-time, ten minutes: send it back to publish_draft only after the engineer says yes"New value: +"One-time: send it back to publish_draft only after the engineer says yes. Never show it to them"

addedOutput schema / properties / details

Added value: +{
+  "description": "Where and under whose byline it goes live: show it beside the question if they ask",
+  "type": "string"
+}

changedOutput schema / properties / question / description

Previous value: -"What to ask the engineer, word for word"New value: +"What to ask the engineer, word for word: \"Publish '<title>' now? (yes/no)\", then anything else they are agreeing to"

addedOutput schema / properties / reasked

Added value: +{
+  "description": "True when the confirmation sent no longer fitted (it lapsed, or the text or its checks moved): ask this fresh question instead, plainly",
+  "type": "boolean"
+}

Changed1 schema field changedOct 22, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "properties": {
+    "confirmation": {
+      "description": "One-time, ten minutes: send it back to publish_draft only after the engineer says yes",
+      "type": "string"
+    },
+    "confirmed_by": {
+      "type": "string"
+    },
+    "expires_in_seconds": {
+      "type": "integer"
+    },
+    "id": {
+      "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"
+    },
+    "overridden": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "preview_url": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "question": {
+      "description": "What to ask the engineer, word for word",
+      "type": "string"
+    },
+    "run": {
+      "type": "string"
+    },
+    "status": {
+      "enum": [
+        "confirmation_required",
+        "publishing",
+        "not_published"
+      ],
+      "type": "string"
+    },
+    "text_hash": {
+      "type": "string"
+    },
+    "title": {
+      "type": "string"
+    },
+    "url": {
+      "description": "Where it goes live",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "id",
+    "status",
+    "next"
+  ],
+  "type": "object"
+}

AddedOct 21, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already mark it read-only, idempotent and non-destructive, and the description adds material behavior on top: a required Microsoft sign-in with blog.write scope, a single-use confirmation bound to the exact saved text and its checks, and defined failure output. That is exactly the context an agent needs about auth and token lifetime, neither of which the annotations express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is dense and mostly earns its place, but the auth requirement is front-loaded ahead of the actual purpose, and the sentence 'A read: whether one of your drafts may be published now...' is awkwardly constructed. Leading with the check and following with auth and the follow-up call would be easier to parse.

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?

With an output schema present, the description doesn't need to enumerate return values, and it covers auth, the success path, the failure path and the handoff to publish_draft. One gap: it never says whether check_draft/lint_draft should be run before this, despite referring to 'its checks' as though that were established.

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%, so the baseline is 3, but the description goes further by explaining that the confirmation is one-time and tied to this exact text, and that the override must be passed identically to publish_draft. That cross-tool coupling is not derivable from the schema alone, though it still doesn't explain what happens if the same confirmation is reused.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies a read-only check on one of the caller's own drafts and states what it returns: a publishability verdict plus a ready-made question to ask the engineer. It names publish_draft as the downstream tool, which differentiates it from siblings, though the framing 'A read:' is indirect and the core verb (check/review publishability) is buried after the auth sentence.

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?

It gives an explicit ordered workflow: call this first, and only after the engineer says yes call publish_draft with the id, the confirmation, and the same override. It also covers the negative branch ('if it can't be published yet, it says why and what to do'), so there is no ambiguity about sequencing or alternates.

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.