TechFabric

Start a post with an interview

start_post

Read-onlyIdempotent

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). Start here when asked to write, draft or start a blog post or case study for techfabric.com, before writing anything, even inside the techfabric-web repository (never a local file): brainstorm mode (one question about real work first: what happened, what surprised you), then the interview for a post, a case study or an explainer, about seven questions tailored to the topic and to today's brief. First look through the repository, and the site with search and get_page, then send suggested (your answers from what you found) so the engineer only confirms or corrects; it also offers what techfabric.com already published on the topic (published). With form: true, a client that answers forms and shows no apps shows them as one form; otherwise ask them in chat and call again with answers. Returns their answers as sources for submit_draft, then outline and check_outline before any prose. A read: nothing is filed or claimed.

Input Schema

Name	Required	Description	Default
`form`	No	true: in a client that shows forms and no MCP Apps view, ask the engineer the interview as one form. Send it only when the engineer wants a form; left out, the questions come back to ask in chat.
`kind`	No	What the engineer is writing: "post" (the default), "case-study", or "explainer" (a post on news or a feature; submit it as kind "post").	post
`brief`	No	Tailor the questions to the brief the engineer holds today (get_brief claims one; this only reads it).
`topic`	No	What it is about, in the engineer's words. Leave it out with brief: true.
`answers`	No	The engineer's own answers, by question id, word for word, once they've given them in chat: returned as sources for submit_draft.
`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.
`suggested`	No	Your suggested answer to each question, by its id, from the repository and the engineer's notes: shown to them to confirm or correct, never sent as their words.

Output Schema

Name	Required	Description
`kind`	Yes
`mode`	No	The writing partner's mode (editorial/voices-of-techfabric.md): brainstorm first, draft only when asked
`next`	No
`brief`	No
`topic`	No
`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.
`answers`	No
`ask_how`	Yes	form: the engineer answered the form; chat: ask them these questions in chat; answered: the answers came with the call
`missing`	No	Required questions still unanswered: ask the engineer for these before the outline
`sources`	No	The engineer's answers, word for word, as the text to send as sources with submit_draft and update_draft
`post_type`	No	The post type this interview is for: what the call sent, else story (whats-new for an explainer). Not for a case study
`published`	No	What techfabric.com already published on the topic (posts, case studies, service pages), from the site's own index: offered to the engineer to confirm, never as their words
`questions`	Yes
`brainstorm`	No	How to brainstorm with the engineer before any outline: one focused question at a time, about real work
`next_action`	Yes
`outline_needs`	No
`post_type_question`	No	When the call sent no post_type: ask the engineer this, with your suggestion, and send their choice as post_type to check_outline, lint_draft and submit_draft

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."

Changed3 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 this interview is for: what the call sent, else story (whats-new for an explainer). Not for a case study",
+  "enum": [
+    "story",
+    "perspective",
+    "whats-new",
+    "personal"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / post_type_question

Added value: +{
+  "description": "When the call sent no post_type: ask the engineer this, with your suggestion, and send their choice as post_type to check_outline, lint_draft and submit_draft",
+  "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"
+}

Changed2 schema fields changedOct 27, 2026

removedInput schema / properties / form / default
```
Removed value: -true
```

changedInput schema / properties / form / description

Previous value: -"false: never show the form; return the questions to ask in chat."New value: +"true: in a client that shows forms and no MCP Apps view, ask the engineer the interview as one form. Send it only when the engineer wants a form; left out, the questions come back to ask in chat."

Changed1 schema field changedOct 27, 2026

addedOutput schema / properties / published

Added value: +{
+  "description": "What techfabric.com already published on the topic (posts, case studies, service pages), from the site's own index: offered to the engineer to confirm, never as their words",
+  "items": {
+    "properties": {
+      "summary": {
+        "type": "string"
+      },
+      "title": {
+        "type": "string"
+      },
+      "type": {
+        "type": "string"
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "title",
+      "url",
+      "summary",
+      "type"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changed2 schema fields changedOct 24, 2026

addedOutput schema / properties / brainstorm

Added value: +{
+  "description": "How to brainstorm with the engineer before any outline: one focused question at a time, about real work",
+  "properties": {
+    "answer_id": {
+      "description": "The answers key for the engineer's answer to first_question, kept in the sources like the rest",
+      "type": "string"
+    },
+    "first_question": {
+      "type": "string"
+    },
+    "steps": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "why": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / mode

Added value: +{
+  "description": "The writing partner's mode (editorial/voices-of-techfabric.md): brainstorm first, draft only when asked",
+  "enum": [
+    "brainstorm"
+  ],
+  "type": "string"
+}

AddedOct 22, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Beyond the readOnly/destructive annotations, it discloses the auth prerequisite (Microsoft sign-in, scope blog.write, TechFabric engineer only), the side-effect profile ("A read: nothing is filed or claimed"), and the two-call interview loop. It does not cover what happens if the sign-in is missing or expired, nor any retry/failure behavior, which keeps it short of a 5 for a tool with this much interaction surface.

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 trigger statement is front-loaded, but the body is a dense run-on chain of clauses ("about seven questions tailored to the topic and to today's brief. First look through the repository, and the site with search and get_page, then send suggested...") that mixes workflow, permissions, and parameter notes in one breath. Little is outright wasted, yet the ordering and sentence length make it harder to parse than it needs to be.

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?

For a zero-required-parameter, nested-object tool with an output schema present, the description covers the parts structured fields cannot: auth, the discovery steps before suggesting answers, the confirm-or-correct intent of 'suggested', and the required handoff sequence to submit_draft/outline/check_outline. Nothing an agent needs to call this correctly and route the result is 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 description coverage is 100%, so the schema already documents all seven parameters, and the description largely restates them: form behavior, topic vs brief, answers, suggested. Where it adds real meaning is the sequencing rule that suggested must come from the repository and notes and is "never sent as their words," and the distinction between suggested and answers, but that is incremental over the schema text.

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?

"Start here when asked to write, draft or start a blog post or case study for techfabric.com" names the verb, the resource and the exact trigger, and the description immediately distinguishes itself from siblings by pointing forward to submit_draft, outline and check_outline and by warning it is "never a local file." An agent can tell this is the entry-point interview tool, not the drafting or editing tools, without opening the schema.

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 explicit when-to-use (before writing anything, even inside the techfabric-web repo), when-not (never a local file), and named follow-on alternatives (search and get_page first, then submit_draft, outline, check_outline before any prose). The two-phase interaction is spelled out: ask in chat and call again with answers, or pass form: true only when the client supports forms and the engineer wants one.

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.