TechFabric

Check an outline

check_outline

Read-onlyIdempotent

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). A read, about a millisecond, free: an outline (title options, the opening's two sentences, four to six sections with a line each, the diagram, the FAQ questions; a case study's four sections) against the title, opening, heading and FAQ rules, before any prose; the opening's device and first words are held to the last ten published posts (editorial/voices-of-techfabric.md). Fix what it finds and call again until ready; then show the engineer outline_markdown and draft only after their OK.

Input Schema

Name	Required	Description	Default
`faqs`	No	Three or more questions a reader would search for. Not for a case study.
`kind`	No		post
`reader`	No	Who the post is for.
`titles`	Yes	Two or three title options, each one clause naming the subject.
`diagram`	No	What the diagram draws, step by step, and its point. Not for a case study.
`opening`	No	The opening's first two sentences: the way this story opens (a device the last ten posts left free: editorial/voices-of-techfabric.md), with one concrete detail and TechFabric doing the work by the second sentence. Not for a case study.
`sections`	Yes	Four to six for a post; Challenge, Strategy, Solution and Results for a case study. The FAQ isn't one of them.
`post_type`	No	The post type, which sets the opening rule and how hard the fact-check reads it. story (the default): work someone at TechFabric did. The opening has TechFabric doing that work by paragraph two, and every claim gets the full fact-check. perspective: a talk or conference the author attended, a conversation with an industry leader, others' work, or our view of what's possible. TechFabric's view by paragraph two ("we think", "we'd", "I believe" count). What a speaker or another company said is attributed in the sentence ("In her demo, ...") and must match what the author provided; forward-looking views need no source. whats-new: a new feature in AI, Databricks or related tech, and how it could help future projects. Open on what changed (its date and source), then our view. Product facts (name, preview or GA, date, what it does) are checked against the vendor's docs or release notes; forward-looking views need no source. personal: the author's own essay or position, in the first person, about where the work or the industry is going and what people should do. Opening and fact-check as perspective, and the only type that may take the memo register: conviction carried as "I believe" and the reader addressed as "you" throughout, up to three bold thesis sentences, one "this is not X" thesis reframe and a closing call to act (other types keep every slop rule, though a perspective opening may still state its view as "we think" or "I believe"). Never for an engineer explaining a feature or their own project. Choose personal only when the engineer writes in their own voice about a position, never for an engineer explaining a feature or their project. Left out, it is story; an explainer is always whats-new. Not for a case study.
`meta_title`	No	A search title of 60 characters or fewer, only when a title runs longer.
`unattended`	No	true in a scheduled run with nobody to approve the outline: a passing outline goes straight to drafting.

Output Schema

Name	Required	Description
`kind`	No
`next`	No
`items`	Yes
`notes`	No
`ready`	Yes
`voice`	No	How every sentence is said (editorial/voices-of-techfabric.md, "Before you write a sentence"): follow it in the outline, the draft and every rewrite.
`failing`	No
`post_type`	No	The post type the outline was checked as (story when none was sent). Not for a case study
`next_action`	Yes
`rewrite_plan`	No
`outline_markdown`	Yes	The outline as Markdown: show it to the engineer for their OK

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 4, 2026

changedInput schema / properties / post_type / description

Previous value: -"The post type, which sets the opening rule and how hard the fact-check reads it. story (the default): work someone at TechFabric did. The opening has TechFabric doing that work by paragraph two, and every claim gets the full fact-check. perspective: a talk or conference the author attended, a conversation with an industry leader, others' work, or our view of what's possible. TechFabric's view by paragraph two (\"we think\", \"we'd\", \"I believe\" count). What a speaker or another company said is attributed in the sentence (\"In her demo, ...\") and must match what the author provided; forward-looking views need no source. whats-new: a new feature in AI, Databricks or related tech, and how it could help future projects. Open on what changed (its date and source), then our view. Product facts (name, preview or GA, date, what it does) are checked against the vendor's docs or release notes; forward-looking views need no source. personal: the author's own essay or position, in the first person, about where the work or the industry is going and what people should do. Opening and fact-check as perspective, and the only type that may say \"I believe\", address the reader as \"you\", bold up to three thesis sentences, make one \"this is not X\" thesis reframe and close on a call to act. Never for an engineer explaining a feature or their own project. Choose personal only when the engineer writes in their own voice about a position, never for an engineer explaining a feature or their project. Left out, it is story; an explainer is always whats-new. Not for a case study."New value: +"The post type, which sets the opening rule and how hard the fact-check reads it. story (the default): work someone at TechFabric did. The opening has TechFabric doing that work by paragraph two, and every claim gets the full fact-check. perspective: a talk or conference the author attended, a conversation with an industry leader, others' work, or our view of what's possible. TechFabric's view by paragraph two (\"we think\", \"we'd\", \"I believe\" count). What a speaker or another company said is attributed in the sentence (\"In her demo, ...\") and must match what the author provided; forward-looking views need no source. whats-new: a new feature in AI, Databricks or related tech, and how it could help future projects. Open on what changed (its date and source), then our view. Product facts (name, preview or GA, date, what it does) are checked against the vendor's docs or release notes; forward-looking views need no source. personal: the author's own essay or position, in the first person, about where the work or the industry is going and what people should do. Opening and fact-check as perspective, and the only type that may take the memo register: conviction carried as \"I believe\" and the reader addressed as \"you\" throughout, up to three bold thesis sentences, one \"this is not X\" thesis reframe and a closing call to act (other types keep every slop rule, though a perspective opening may still state its view as \"we think\" or \"I believe\"). Never for an engineer explaining a feature or their own project. Choose personal only when the engineer writes in their own voice about a position, never for an engineer explaining a feature or their project. Left out, it is story; an explainer is always whats-new. Not for a case study."

Changed2 schema fields changedNov 2, 2026

addedInput schema / properties / post_type

Added value: +{
+  "description": "The post type, which sets the opening rule and how hard the fact-check reads it. story (the default): work someone at TechFabric did. The opening has TechFabric doing that work by paragraph two, and every claim gets the full fact-check. perspective: a talk or conference the author attended, a conversation with an industry leader, others' work, or our view of what's possible. TechFabric's view by paragraph two (\"we think\", \"we'd\", \"I believe\" count). What a speaker or another company said is attributed in the sentence (\"In her demo, ...\") and must match what the author provided; forward-looking views need no source. whats-new: a new feature in AI, Databricks or related tech, and how it could help future projects. Open on what changed (its date and source), then our view. Product facts (name, preview or GA, date, what it does) are checked against the vendor's docs or release notes; forward-looking views need no source. personal: the author's own essay or position, in the first person, about where the work or the industry is going and what people should do. Opening and fact-check as perspective, and the only type that may say \"I believe\", address the reader as \"you\", bold up to three thesis sentences, make one \"this is not X\" thesis reframe and close on a call to act. Never for an engineer explaining a feature or their own project. Choose personal only when the engineer writes in their own voice about a position, never for an engineer explaining a feature or their project. Left out, it is story; an explainer is always whats-new. Not for a case study.",
+  "enum": [
+    "story",
+    "perspective",
+    "whats-new",
+    "personal"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / post_type

Added value: +{
+  "description": "The post type the outline was checked as (story when none was sent). Not for a case study",
+  "enum": [
+    "story",
+    "perspective",
+    "whats-new",
+    "personal"
+  ],
+  "type": "string"
+}

Changed1 schema field changedOct 30, 2026

addedOutput schema / properties / voice

Added value: +{
+  "description": "How every sentence is said (editorial/voices-of-techfabric.md, \"Before you write a sentence\"): follow it in the outline, the draft and every rewrite.",
+  "type": "string"
+}

Changed1 schema field changedOct 24, 2026

changedInput schema / properties / opening / description

Previous value: -"The opening's first two sentences: the reader's problem in their words with one concrete detail, then who we are and our first-hand angle. Not for a case study."New value: +"The opening's first two sentences: the way this story opens (a device the last ten posts left free: editorial/voices-of-techfabric.md), with one concrete detail and TechFabric doing the work by the second sentence. Not for a case study."

AddedOct 22, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotent/non-destructive; the description adds real context beyond them — Microsoft sign-in with blog.write scope, ~1ms latency, free, the iterate-until-ready loop, and the human approval gate before drafting. Auth scope and the human gate are the most valuable additions.

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?

Dense but largely front-loaded and purposeful; each clause (auth, cost, rules checked, iteration, approval gate) contributes something. The semicolon-heavy single paragraph is slightly hard to parse but not padded.

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, return values needn't be explained, and the description still tells the agent auth needs, cost/latency, what is validated, and the follow-up workflow. Complete enough for a 10-parameter validator, with only sibling disambiguation 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 90%, so the baseline is 3. The description reinforces a few semantics (opening's device compared against the last ten published posts, case-study section shape), but most parameter meaning is already carried by the schema's own descriptions.

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 states a specific action: validating an outline (titles, opening, sections, diagram, FAQs) against the title/opening/heading/FAQ rules before prose is written. It even enumerates what an outline contains and how a case study differs. It does not name siblings like check_draft or lint_draft, so it falls short of a 5.

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?

Clear workflow guidance: run it on the outline, 'Fix what it finds and call again until ready', then show outline_markdown and draft only after the engineer's OK, with the unattended flag changing that gate. There is no explicit comparison against alternative validation tools, so it is not 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.