TechFabric

Search TechFabric's published site: blog posts, service and solution pages, case studies, city pages and events. Returns each match's title, URL, summary, date, author and type, best first. Read a result in full with get_page. Drafts are private: list_drafts lists a signed-in engineer's drafts; a TechFabric engineer connects with Microsoft (the client's Connect or Authenticate button) to list and write them.

One published page of www.techfabric.com as clean Markdown, with its title, search title (metaTitle), description, date, updated, author, tags, FAQs as question and answer pairs, and canonical URL. Takes a URL, a path or a post's slug. Only published, indexable pages. Drafts are private: list_drafts lists a signed-in engineer's drafts; a TechFabric engineer connects with Microsoft (the client's Connect or Authenticate button) to list and write them.

TechFabric's published blog posts, newest first, optionally only those with a tag, by an author, or dated on or after a day. Drafts are private: list_drafts lists a signed-in engineer's drafts; a TechFabric engineer connects with Microsoft (the client's Connect or Authenticate button) to list and write them.

Every service, solution, Databricks, AI, cloud, software, accelerator and product page on techfabric.com: its name, URL, kind and summary, exactly as the live page states them. Read one in full with get_page.

Takes no parameters.

Interactive: walk through a published techfabric.com post or case study: its diagram (the Mermaid flowchart it publishes) as steps in the order it flows, each step tied to the section it's about, with that section's opening in the page's own words and a link to it. A page with no diagram steps through its sections. Takes a URL, a slug or a topic (the closest post or case study). In a host that renders MCP Apps it opens as a view to click through; the text is complete without it. For example: "walk me through this post step by step", "show me how this works", "explain the diagram in this case study".

Interactive: two or three of TechFabric's published case studies side by side: each one's challenge, strategy, solution and results, in its own words (the bold statement and the start of each section), with its client, sector and stack where the case study states them, and links to each section. Name them by slug or URL, or give a topic for the closest three; with neither, the list to choose from. Nothing is added that the case studies don't publish. For example: "compare your case studies", "how did these two projects differ", "show me your Databricks projects side by side".

Interactive: a Databricks readiness and migration check: eight multiple-choice questions (where the data runs now, how well the estate is known, access, deployment, failures, cost visibility, the team, the first use), scored by fixed points into five areas, with a readout: where to start, what to work on first, and links to TechFabric's own service pages, posts and Databricks Field Guide chapters, then the contact page with the matching topic. Call it without answers for the questions; with form: true, a client that shows forms asks them in one; a host with MCP Apps scores them in its view, and otherwise ask the reader in chat and send answers. The answers are scored and never stored or logged. For example: "are we ready for Databricks", "assess our migration readiness", "where should we start with Databricks".

Interactive: a multiple-choice quiz from a published post's own FAQs: each question is one of its FAQs, the right option is the post's answer, and the others are answers the site gives to other questions; no model writes them. Each has its answer, the post's explanation and a link. With form: true, a client that shows forms asks the questions in one and scores it; a host with MCP Apps scores it in its view; otherwise the text lists the questions and the key: ask the reader before revealing it, then send their letters as answers to score. A reader who kept a resume code (Keep my progress, in a host without Fabric's view state) picks up with resume alone. For example: "quiz me on this post", "test what I learned", "check my understanding".

Interactive: draw your answer as a card the reader can use: a comparison with a verdict, a plan as steps, a calculator whose chart follows its sliders, a quiz, a table, a diagram. Write it as an A2UI v0.9.1 document; the tool checks that it will draw (a document that won't comes back as an error listing what to fix; its facts aren't checked), returns all of it as text, and labels it as composed by you. Call it whenever the answer has a shape: the reader asks to compare ("compare", "X vs Y", "pros and cons", "trade-offs", "which is better for"), for a plan ("plan", "roadmap", "migration steps", "rollout", "timeline"), to "show me", "draw", "chart" or "visualise" something, or for "a table of" options, rather than answering with a long Markdown table or list; a post, a case-study comparison or a readiness check go to explore_post, compare_case_studies and assess_databricks_readiness first. Get the facts first with search or get_page and pass those URLs as sources: only pages this site publishes are listed. In a host that renders MCP Apps it opens as the card; the text is complete without it. For example: "draw that Databricks comparison as a card", "lay out the migration plan step by step", "show me the cost options side by side", "compare Fabric vs Databricks", "pros and cons of a lakehouse", "a rollout timeline for the migration".

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). Today's topic for a daily post, claimed for you for 24 hours (asking again returns the same one): the topic, angle, target search, sources, internal links, and the brief_id to pass to submit_draft. Status none, with the reason, when there is nothing today: stop there. No model is called. Ask the engineer for first-hand detail; never invent it.

Takes no parameters.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). The site's rule-based checks (slop, claims, known errors, voice, opening, title, description, FAQ, diagram, images, links, a case study's rules) on a post's Markdown, frontmatter included: about a second, free, filing nothing. Iterate with this, never with check_draft: rewrite each passage in rewrite_plan as its fix says and lint again until ready, then review the draft against the judge_rubric it returns. With id, it lints a draft of yours: its saved text, or the markdown you send as an edit to it.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). The final verification publish_draft needs. With id: the full checks on your saved draft (judge, slop classifier, fact-check), about a minute; call it after lint_draft passes, never to iterate. Each call waits up to 25 seconds and then reports progress: call it again, never two at once, for the answer (nothing runs twice; a client with the tasks extension gets a task). Right after submit_draft it waits while the draft is filed. Without id it checks markdown and files nothing, which publish_draft doesn't count. On next_action confirm, send first_hand_to_confirm back as first_hand: the engineer confirms, never you.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). File a post (or, with kind "case-study", a case study) under the engineer's byline, exactly as written: the site builds its preview and emails it to them. Send the whole Markdown with frontmatter (title and description at least), the engineer's own words as sources, and brief_id when it comes from get_brief, or from_idea when it continues an idea they emailed. Lint it clean first. Returns the draft's id and text_hash; next, check_draft with the id. Never publishes.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). Save a new version of your draft (state drafted): the whole Markdown, and base_hash, the hash of the version you edited (draft.base_hash from get_status, or your last update_draft's text_hash). Answers in a second or two; the preview rebuilds in the background. It runs no checks: lint_draft the edit first, then check_draft with the id. Refused if the draft changed since base_hash or is open in the browser editor. The engineer may also edit and save it in the draft app: start each edit from a fresh get_status. Never publishes.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). Lists your drafts (blog posts, case studies and revisions of live posts), newest first: each one's id, title, kind, state (writing, question_for_you, drafted, checks_failing, ready_to_publish, published and the rest), created and updated dates, preview link and next_action. Filter by state, kind and creation date (created_after, created_before: "yesterday" is the day before the answer's today), and page with cursor. The editor may pass all for everyone's; the site owner, stale: true for his owner queue (drafts stuck over two days). Reads only. Then get_status with an id for one draft in detail.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). Where one of your drafts stands (by its id; list_drafts lists them), with next_action: the single next step and the call to make. Also its saved Markdown and base_hash (for update_draft; read them again before each edit, as the engineer may have saved one in the draft app), what is failing, the last check, the preview link and, once published, live_url. A fact the blog writer waits on is in the status; form: true asks it as a form. Never the editor link: to edit in the browser, call open_editor. To show the engineer the draft itself ("show me the preview", "show it here"), call preview_draft, never fetch the preview link.

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 '<title>' 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.

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.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). Interactive: show one of your drafts here. Call it whenever the engineer asks to show, see or open the preview, to show it here, or what the draft looks like (for example: "show me the preview", "show it here", "can I see the draft", "open the preview", "what does it look like"). A read: the draft as techfabric.com renders it, with its last checks (each marked as one the engineer may publish past or one that must pass) and whether Publish may run, rendered inline as the draft app where the host shows MCP Apps. In any host its text starts with the preview link: show it to the engineer. Never fetch the preview link yourself or rebuild the page as an artifact or HTML: this is the preview.

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.

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.

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.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). Propose changes to a filed draft as a redline the engineer decides on: each change a passage of the saved markdown (find, exactly as it is), what you propose instead (replace) and why (reason), at most 12 changes and 160 rewritten words each. Saves nothing. Show the engineer redline_text and send what they accept to apply_edits (or ask: true, a form where the client shows one). Use it for every fix to a filed draft, instead of update_draft.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). The engineer's decision on a proposal (propose_edits): the changes they accepted are applied to the saved text and saved (as update_draft saves), the rule-based checks run at once and the full check starts in the background. Only what the engineer accepted, never your own choice. Never publishes.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). One question only the engineer can answer (what was measured, who it was for, what happened): returned for you to ask in chat (or, with form: true, asked in a form where the client shows one); call again with their answer, word for word. The answer is stored as one of the draft's sources, which the fact-check reads as their own words. Never answer it yourself.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). A read: what your agent needs to draft a LinkedIn post about a published techfabric.com post, any post on the site. Its key points and first-hand sentences, its link with the LinkedIn campaign, the engineer's voice notes, the social rules and LinkedIn's lengths. No model is called and nothing is posted: draft the post from it, check it with lint_social, and show the engineer the text to post themselves.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). A read: the site's writing rules and the social rules on a LinkedIn post's text (the AI tells, the slop, claims, announcement openers, engagement bait, hashtags), its length, what shows before "see more", and, with post, whether it links the post. Rewrite each finding and lint again until ready. Posts nothing.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). A read: what your agent needs to draft a Reddit post or thread answer in your own voice, from a published techfabric.com post or your own notes. The subreddit's rules, the frame (a plain title; first person; the problem, what you tried, what worked, your numbers), the disclosure line, the optional link last, a checklist and the steps to post it yourself. Send draft to check it: the site's writing rules plus Reddit's (no hashtags, no 'check out our', no call to action, substance before any link). No model is called and nothing is posted, voted or commented.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). A read: how one of your own published posts is doing in Google (the blog's editor: any post). Search Console's clicks, impressions, CTR and average position for the last 28 days against the 28 before, the searches it shows for, whether Google has indexed it, and what to improve, each with the numbers behind it. Without post: all your posts with their last 28 days. Searches from the US only, so totals are lower than Search Console's all-countries view; cached for six hours. No model is called and nothing changes: revise_post changes a live post, only after the engineer agrees.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). A read: the pages of ours a draft or post should link (posts, services, solutions and case studies sharing its distinctive words), each with why and where (the section, the paragraph and a phrase for the anchor), never one it already links; and the open searches that match your own work: searches people make that competitors rank for, or that we target, and that no post of ours answers yet. Send markdown, id (one of your drafts) or post (one of your published posts); nothing at all for topics only. Deterministic, no model; it changes nothing.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). A read: every ```mermaid block in a post (or one mermaid source), as the site will treat it. For each: its lines in the post, its caption, whether the site's mermaid parses it (with the error and its line in the post when it doesn't), and the diagram rules' findings (a caption that states the point; no fact in a label the section's text doesn't say). In a host that renders MCP Apps it opens the diagrams drawn in the site's theme. Files nothing, calls no model; use it while drafting, then lint_draft the whole post.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write), and only the site owner's is accepted (the Fabric Agents brief automation runs as him). A read: the briefs proposed and not yet taken, the competitor-gap and backlog searches no post or idea covers yet, the 30 most recent posts and the ideas in flight. What the brief automation reads before it proposes. Deterministic, no model; it changes nothing.

Takes no parameters.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write), and only the site owner's is accepted (the Fabric Agents brief automation runs as him). Adds one brief to the pool get_brief offers engineers, first and matched to their work: topic, why (the evidence), angle, sources, target_query, for_author. Refused with the reason, nothing stored, when a live post or an idea in flight covers it, an open proposal already is it, or today's 3 are used; the same topic again is the same brief. Drafts and publishes nothing; no model.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). When the engineer asks to open or edit a draft, or one of their published posts, in the browser: a link to the browser editor that works once and expires in 15 minutes. Show it to them as a link and say so; never open or fetch it yourself. id is one of their drafts; post (or a published draft's id) opens or finds the post's revision, as revise_post does. Only their own drafts and posts (the site owner: any). The editor link in their email is unchanged.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). Adds an image to one of your own drafts without the browser editor: returns a one-time upload URL and its Authorization header (15 minutes, one PNG, JPEG, WebP or GIF file of the type given, up to 10 MB), and the curl command that PUTs the file from the engineer's machine. Run that curl as given: the token goes only in the header, never in the URL. Location and camera metadata are removed. Then place_image gives the snippet to put in the post. Pass alt only as the engineer's own words.

Requires a TechFabric engineer's Microsoft sign-in (scope blog.write). A read: the Markdown for an image already uploaded to your draft, ``, and with markdown the post with it in after the paragraph `after` names (or at the end) and the image rules read on it. Alt text is required (WCAG 2.1): without it, or with one that is the file name, "screenshot", the caption again, under 5 or over 250 characters, it returns the question to ask the engineer and no snippet: never write one yourself. decorative: true, only on the engineer's word, places a decorative image with empty alt. Saves nothing: save the post with update_draft.