TechFabric

Publish your draft

publish_draft

Destructive

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). Publish one of your drafts to techfabric.com, only after the engineer confirms, once check_draft with the id has passed on exactly the saved text. The first call publishes nothing: with the draft card showing it waits for the engineer's Publish there; else a form, or a one-time confirmation you send back only after their yes. Never in a scheduled or unattended run. override names wording checks the engineer chooses to publish past (never the hard set, the fact-check, slop, quality, opening or ending). confirm_via "token": always return the one-time confirmation instead of a form, for a UI that asks the engineer itself.

Input Schema

Name	Required	Description
`id`	Yes	The idea id of your own draft
`override`	No	Publish anyway: the failing check ids (as check_draft reports them, such as gate:buyer) the engineer chooses to publish past. Only wording and style checks; the hard set (the page working, claims, our own spend, secrets) always has to pass. Send the same list on the confirming call
`confirm_via`	No	How the engineer is asked. Default: elicitation where the client supports it. "token": the first call returns a one-time confirmation instead, for a UI (an MCP App's Publish button) that asks the engineer itself
`confirmation`	No	Only on the second call: the confirmation the first call returned, sent back after the engineer said yes

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 20, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the required Microsoft sign-in and blog.write scope, the fact that the first call publishes nothing, the confirmation handshake, and the restriction that override cannot bypass hard checks. These are significant behavioral details for a destructive, non-idempotent operation.

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 description is front-loaded with the core action and safety prerequisite, but it becomes a dense run-on explanation of confirmation paths, override semantics, and token behavior. The information is useful, yet the structure is harder to parse than necessary.

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?

The description covers the full workflow an agent needs: auth requirements, check prerequisites, engineer confirmation, two-step publishing behavior, override limits, and unattended-run prohibition. With an output schema present, return-value details need not be explained.

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%, so the parameter descriptions already carry most of the meaning. The tool description reinforces override and confirm_via behavior in context, but it largely repeats what the schema says rather than adding new syntax or constraints.

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?

The description states a specific verb and resource: publish one of your drafts to techfabric.com. It also ties the action to check_draft passing and engineer confirmation, which distinguishes it from sibling review, submit, and edit tools.

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?

The description gives explicit preconditions: the engineer must confirm, check_draft must have passed on exactly the saved text, and the tool must never run scheduled or unattended. It also explains the two-step confirmation workflow and when to use the token confirmation path.

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.