More Targeted Content Editing With Block MCP ![rw-book-cover](https://i.ytimg.com/vi/ZZ-FkAIoG1g/sddefault.jpg) 🔗 **Source:** [More Targeted Content Editing With Block MCP](https://www.youtube.com/watch?v=ZZ-FkAIoG1g) > [!note]+ Document Notes > tags: [block-mcp, wordpress-ai, model-context-protocol, gutenberg-blocks, supply-chain-security, developer-tooling] > author: Eric Karkovack > source: WP Minute Podcasts > reference: https://www.youtube.com/watch?v=ZZ-FkAIoG1g > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: More Targeted Content Editing With Block MCP > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [WP Minute](https://thewpminute.com) — the publisher; full episode lives on the WP Minute Plus channel. - [Auto Mem by Jack Arturo](https://github.com/jackarturo) — the memory system referenced in the demo (search GitHub for "Auto Mem WordPress"). - [GravityKit](https://www.gravitykit.com) — Zack Katz's company, builder of the Block MCP tool. ## 📝 Summary - Zack Katz of GravityKit gives a short live demo of Block MCP, a WordPress Model Context Protocol server that edits the site at the block level instead of by scanning raw markup or CSS selectors. Eric Karkovack of WP Minute hosts. - It matters because most AI editing tools rescan the whole page after every change and can shred your block structure. Block MCP solves both: stable reference IDs skip the rescan, and a post-edit validation step runs the result through WordPress to confirm the block structure still renders as expected. - Key stakeholders: WordPress site owners using AI to edit content, plugin developers building MCP servers, GravityKit (vendor), and the broader WordPress AI tooling community (Core AI, the MCP/Abilities ecosystem). - Risks and tradeoffs: it's vendor tooling tied to a specific stack (Auto Mem for memory, GravityKit's server); "verified" claims rest on WordPress's own render path, so trust depends on that check being honest. The clip is a vendor demo, not an independent benchmark. - Bottom line: targeted, block-aware editing with stable IDs plus a render-validation gate is a meaningful step past generic "edit the HTML" MCP tools — and it's directly relevant to anyone running their own block MCP (like Courtney's block-mcp-courtneyr-dev). ## 📖 Main Content - **What "targeted" means here.** The demo edits one H2 heading by referencing the text you want to change. Block MCP is "optimized for this kind of editing" — you point at content, the tool finds the matching block, and it edits that block only. The specific tool invoked is named `update one block` (an update-single-block operation), which finds the heading by a reference ID and changes it. - **Stable reference IDs = no rescan.** The central technical claim. Other MCP products rescan the page after every edit to figure out the right code to update next. Block MCP assigns stable reference IDs, so after an edit the tool already knows the block is the same one and skips re-scanning. This is the efficiency and reliability win. - **Validation gate after every edit.** After each change, the tool verifies the edit — not just valid HTML, but valid block structure. It runs the result through WordPress itself to confirm WordPress renders it the way the tool expects. If it doesn't, the tool throws an error and tells the AI what failed. Katz frames this as the differentiator: other MCPs make an edit and assume it worked, which can silently destroy block structure. - **Revisions = rollback.** Every change saves a revision, so you can roll back to the state before the edit. - **Memory layer is separate.** The demo uses Auto Mem by Jack Arturo for persistent memory about how you work — that's a complementary tool, not part of Block MCP itself. - **Scope beyond headings.** Katz notes you can move blocks around and edit alt text, and "all of this stuff works out of the box." - **Context (uncertain/contested).** This is a vendor demo segment clipped from a longer interview that also covered securing plugins against supply-chain attacks. No independent measurements of speed or correctness are shown; the "AI can take forever to scan" claim is asserted, not benchmarked. ### 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=ZZ-FkAIoG1g?t=0) Intro — Eric Karkovack - WP Minute episode; segment from an interview with GravityKit's Zack Katz. - Two topics in the full interview: securing plugins against supply-chain attacks, and a live Block MCP demo. - Full episode is on the WP Minute Plus channel; details at wpminute.com. #### ⏱️ [00:00:30](https://www.youtube.com/watch?v=ZZ-FkAIoG1g?t=30) The edit target — Zack Katz - Demo task: change an H2 heading, "A WordPress MCP that knows your site." - You reference the text you want to change; Block MCP is optimized for this kind of targeted editing. - Contrast claim: generic AI "can take forever to scan through and find some specific code or look for a selector." - Prompt used: make it "more punchy," "make it better." #### ⏱️ [00:01:30](https://www.youtube.com/watch?v=ZZ-FkAIoG1g?t=90) Tool loading + memory - The MCP is registered as available to edit the site, so the AI loads the Block MCP tools. - Memory comes from Auto Mem by Jack Arturo — recommended for AI that should remember your work context. #### ⏱️ [00:02:15](https://www.youtube.com/watch?v=ZZ-FkAIoG1g?t=135) Stable reference IDs - The response identifies the target as "the H2 at the start of the know your site section." - Uses a reference ID. Other MCPs rescan the page after every edit; Block MCP's stable IDs mean no rescan — it knows the blocks are unchanged. #### ⏱️ [00:03:10](https://www.youtube.com/watch?v=ZZ-FkAIoG1g?t=190) The edit + verification - Chosen new headline replaces the old one (toward "connect once it already knows your site"). - Tool invoked: `update one block` — finds the specific heading via its reference ID and edits only that block. - Every change saves a revision → rollback is available. - "Verified" step: confirms valid block structure (not just valid HTML) by running through WordPress; throws an error to the AI if the render doesn't match. #### ⏱️ [00:04:10](https://www.youtube.com/watch?v=ZZ-FkAIoG1g?t=250) Refresh + wrap - Browser refresh confirms the live heading changed. - "Simple thing" that's hard for other MCPs to get right. You can also move blocks and edit alt text out of the box. ## 📚 References - [WP Minute](https://thewpminute.com) - [GravityKit](https://www.gravitykit.com) - [Auto Mem (Jack Arturo)](https://github.com/jackarturo) — search "Auto Mem" for the WordPress memory project. - [Model Context Protocol](https://modelcontextprotocol.io) — the open standard the tool builds on. ## 🗣️ Paraphrase - Katz shows that with Block MCP you can point an AI at a specific heading by its text, and the tool edits that one block — no slow scan for selectors or raw code, because the server is built for block-targeted edits. - The two things that set it apart: stable reference IDs that remove the need to rescan the page after each edit, and a verification step that re-renders the result through WordPress to guarantee the block structure is intact, throwing an error if it isn't. Every edit is also a revision you can roll back. ## 📰 Newsletter - Block MCP is one to watch if you're doing AI-assisted WordPress editing. GravityKit's Zack Katz showed it off on the WP Minute: instead of treating your page as a blob of HTML to scan and rewrite, it edits at the block level using stable reference IDs — so the AI doesn't have to rescan after every change. The killer feature is the verification step: after each edit it runs the result back through WordPress to confirm the block structure still renders right, and yells if it doesn't. No more silently mangled blocks. Every edit saves a revision too, so rollback is one click away. Paired in the demo with Auto Mem (Jack Arturo's memory project), it's a glimpse of what disciplined, block-aware AI editing looks like. Catch the full interview — which also covers protecting plugins from supply-chain attacks — on the WP Minute Plus channel. ## ✅ Action Items #### DevRel - Developer advocacy: record a side-by-side demo comparing a generic "edit the HTML" MCP against a block-aware one with stable IDs + a render-validation gate; publish as a talk or short. - Education: write a short "how block-level MCP editing works" explainer (reference IDs, validation gate, revisions) for the Learn WordPress audience. - Developer experience: document the `update_block`/`update one block` pattern and the post-edit verification contract as a reusable template for other MCP server authors. - Developer marketing: position block-aware editing + render validation as the safety story for AI-in-WordPress. - Community management: gather feedback from site owners on whether the validation gate actually prevents broken blocks in real use. - Internal/external/cross-project: align with Core AI on a shared "validate after edit" expectation across MCP servers. #### OSPO - Policy & Governance: define expectations for AI editing tools that mutate site content (rollback required, validation required). - License Compliance: confirm licensing posture of vendor MCP servers (GravityKit) and the Auto Mem dependency before recommending. - Security Management: tie this back to the interview's supply-chain theme — MCP servers that can edit a live site are a high-value attack surface; require provenance and signing. - Software Inventory: track which MCP servers are installed and what write scopes they hold. - Developer Support: offer guidance on safely granting write-scoped MCP tools. - Community Engagement: not applicable to this source — no funding/operator-agreement angle is raised. - Strategic Alignment: feed "validated block edits" into AI-tooling KPIs. #### Community - Maintainers: publish release-hygiene guidance for MCP servers that write to live sites (revisions, validation, error reporting). - Contributors: open a "first issue" set around block-validation helpers other MCP servers could reuse. - Sponsors: not applicable to this source. - Ecosystem: run a coordinated test of multiple block MCP servers against the same edit set to surface structure-destroying bugs. #### WordPress - Core: consider a canonical "render and compare block structure" helper so every MCP/AI tool can validate edits the same way. - Core Performance: profile the rescan-vs-stable-ID difference — does skipping rescans materially cut tokens and latency? - Core AI: adopt "validate the edit through WordPress, surface errors to the model" as a baseline pattern for AI editing tools; build an evaluation set of edits that break block structure. - **Core Program Team:** coordinate MCP/Abilities efforts so block-editing patterns converge. - Mobile: not applicable to this source. - Playground: build a reproducible Playground lab demonstrating block-targeted editing + the validation gate (great teaching module). - Community: not applicable to this source. - Training: turn the explainer into a Learn WordPress lesson on AI-assisted block editing. - Marketing: narrative around "AI that doesn't break your blocks." - Support: document recovery via revisions when an AI edit goes wrong. - Design: not applicable to this source. - Documentation: add DevHub coverage of block-level MCP tools, reference IDs, and the validate-after-edit contract. - Photos: not applicable to this source. - TV: ensure the WP Minute clip and any official demo have accurate captions. - Polyglots: not applicable to this source. - Accessibility: the demo mentions editing alt text — document accessible-by-default AI editing flows. - Meta: not applicable to this source. - CLI: consider wp-cli parity for block-targeted edits and validation. - Hosting: not applicable to this source. - Tide: not applicable to this source. - Openverse: not applicable to this source. - Themes: not applicable to this source. - Plugins: provenance/security review path for MCP-server plugins that gain write access to content. #### The WPCC - Programs: not applicable to this source — no fellowship/microgrant angle raised. - Projects: a documentation sprint on MCP editing patterns would fit. - Funding experiments: not applicable to this source. ### FAIR - Technical independence: stable local reference IDs + WordPress-native validation keep editing logic on the site, not in an opaque external service — good alignment with local-first principles. - Policies and covenants: not applicable to this source. - Productized governance artifacts: not applicable to this source. ## 🧪 Hypotheses - Stable reference IDs reduce token usage and wall-clock latency on multi-edit sessions versus rescan-after-edit MCPs. - The post-edit validation gate catches a measurable share of block-structure corruption that generic MCPs ship silently. - Block-targeted editing produces fewer unintended collateral changes than selector- or HTML-diff-based editing. - Saving a revision per edit increases user trust enough to raise adoption of AI editing. - Pairing a memory system (Auto Mem) with Block MCP improves edit relevance on repeat sessions. ### 📊 Methodology - Build a fixed corpus of pages with varied block structures; run identical edit prompts through Block MCP and 2–3 other MCP servers. - Measure: tokens consumed, latency per edit, count of structure-corruption events, and collateral-change rate (diff blocks not targeted). - Validate corruption independently (render + parse block grammar) rather than trusting each tool's self-report. - A/B the memory layer on/off for repeat-session relevance. ### ❓ Questions - What exactly anchors a "stable reference ID" — block `clientId`, a persisted attribute, or a server-side map — and does it survive re-saves and revisions? - Does the validation gate compare rendered HTML, serialized block markup, or both? - How does it behave with nested/innerBlocks, synced patterns, and third-party dynamic blocks? - What happens when validation fails repeatedly — does the AI retry, and how is that surfaced to the user? - Is the reference-ID scheme interoperable with other MCP servers, or vendor-specific? ### 🔮 Future Research - A shared, open spec for block reference IDs so MCP servers interoperate. - A standard "validate edit through WordPress" helper in Core for all AI tools. - Benchmarks comparing block-aware vs. HTML-aware editing on real sites. - Security model for write-scoped MCP servers tied to the supply-chain concerns from the same interview. ### 💡 Implications - Practice: AI editing in WordPress can move from "risky bulk rewrite" to "surgical, validated, reversible" edits. - Policy: tools that write to live content should be expected to validate and to keep revisions. - Security: write-capable MCP servers expand the attack surface — provenance and least-privilege scoping matter. - Education: clear teaching opportunity on how block-level editing differs from selector/HTML editing. - Funding models: not applicable to this source. ### 🧠 Learning Styles Assessment - Reading level estimate: conversational spoken transcript; roughly Flesch-Kincaid grade 7–8 (short sentences, common words, some jargon like "reference ID," "block structure," "selector"). #### 👀 Visual learners - Present: a live screen demo (the video itself), before/after heading text, visible tool name (`update one block`), token counter on screen. - Improve: an architecture diagram (prompt → tool load → reference ID → edit → validate → revision), a before/after block-tree visual, captioned screenshots. #### 🔊 Aural learners - Present: it's a narrated video/podcast clip with two speakers. - Improve: a 2–3 minute audio summary; clearer enunciation of tool names. #### 🗣️ Verbal learners - Present: terms used in context (reference ID, block structure, selector, revision). - Improve: a glossary defining MCP, reference ID, block structure vs. HTML, and an analogy for stable IDs (like a permanent address vs. re-counting houses each time). #### 🧩 Kinesthetic learners - Present: a real, reproducible edit flow shown end to end. - Improve: a hands-on Playground lab and a step-by-step checklist to try the same edit. #### 🧠 Logical learners - Present: a clear cause→effect chain (stable IDs → no rescan; validation → caught errors). - Improve: a decision tree for what happens on validation pass/fail; a small comparison table vs. generic MCPs. #### 🧑‍🤝‍🧑 Social learners - Present: two-person interview format with back-and-forth. - Improve: a community Q&A or live demo with audience prompts. #### 🧘‍♀️ Solitary learners - Present: short, self-contained clip you can absorb alone. - Improve: reflection prompts ("where would block-level editing help your workflow?"). #### 🌿 Naturalistic learners - Present: not applicable to this source — no environmental framing. - Improve: could frame token reduction as efficiency/waste reduction if useful. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: the content edited is an H2 heading (good semantic structure in the target site). - Improve: ensure the video page has proper headings and landmarks; provide a text transcript. #### Keyboard navigation - Not applicable to this source — it's a video demo, no interactive UI under test here. #### Contrast and readability - Not applicable to this source — can't assess the video player UI contrast from transcript alone. #### Text resizing and reflow - Not applicable to this source. #### Media and captions - Present: YouTube auto-captions likely exist. - Improve: human-reviewed captions and a downloadable transcript; the demo's jargon needs accurate captioning. #### Forms and interactions - Not applicable to this source. #### Standards reference - The demo's mention of editing alt text maps to WCAG 2.2 AA 1.1.1 (Non-text Content); accurate captions map to 1.2.2 (Captions). ### 🌍 DEIB Assessment #### Cultural breadth - Not applicable to this source — short single-locale vendor demo, no regional examples. #### Inclusive language - Present: plain, neutral language; jargon mostly defined in context. - Improve: define MCP and "reference ID" once for newcomers. #### Neurodiversity support - Present: short, chunked, single-task demo — easy to follow. - Improve: add a written step list so it's not audio-only. #### Representation - Present: two named WordPress professionals. - Improve: not much room in a 4.5-minute clip; broader voices live in the full series. #### Psychological safety - Present: friendly, respectful framing; no hostility toward users. - Improve: when criticizing "other MCPs," name behaviors not just competitors to keep it constructive. ### ✅ Logical Validity #### Strong reasoning - Causal: "stable reference IDs → no rescan needed" is a clean cause-effect claim; strong if the IDs truly persist across edits. Located at the reference-ID explanation (~02:15). - Causal: "validate through WordPress → catch block-structure corruption" is sound in principle — running the actual render path is a legitimate check (~03:10–03:40). - To clarify further: show measured before/after (tokens, latency, error counts), not just assertions. #### Fallacies - Unsupported comparison / hasty generalization: "other MCPs can completely destroy your block structure" and "other MCPs don't do this" lump all competitors together without evidence. Location: the verification segment. Fix: cite specific failure cases or benchmarks. - Appeal to convenience: "all of this stuff works out of the box" — a marketing claim, not demonstrated for the move/alt-text cases. Fix: demo those flows too. #### Tone of voice - Enthusiastic, practitioner-to-practitioner, mildly promotional. Example: "Got to love good prompting for AI." Eric plays an affirming co-host ("Nice."). ### 🛡️ DARVO Analysis - Deny: not applicable to this source — no accusation is being deflected. - Attack: mild competitive framing ("other MCPs … destroy your block structure"), but it targets tools, not a person, and isn't a response to criticism — so it's not DARVO-style attack. - Reverse victim/offender: not applicable to this source. - Overall: no DARVO pattern present; this is a product demo, not a defensive or accusatory exchange. ## 🎯 Conclusion - Bottom line: Block MCP edits WordPress at the block level using stable reference IDs (no rescan) and validates every edit by running it through WordPress (catching block-structure corruption other tools ship silently), with a revision saved per edit for rollback. That's a real step up from generic HTML/selector-based AI editing. - Practical next steps for readers: if you run your own block MCP (like block-mcp-courtneyr-dev), check whether your edits are validated through WordPress's render path and whether you keep revisions — those two practices are the durable lessons here. Watch the full WP Minute Plus interview for the supply-chain-security half. Treat speed/correctness claims as vendor assertions until you benchmark them yourself. ## 🔄 Refactor Appendix — More Targeted Content Editing With Block MCP > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. ### 📚 Literature Atoms (H3) #### [H1] Stable reference IDs remove the post-edit rescan > [!quote] ID:rw_pending > "We have stable reference IDs. That means that you don't have to rescan the page." **Context & use**: - ~02:15 in the demo, explaining what sets Block MCP apart from other MCP products. - Matters because rescanning after every edit burns tokens and time; stable IDs are the efficiency mechanism behind "targeted" editing. **Tags**: #xref **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> #### [H2] Block MCP validates edits through WordPress's own render > [!quote] ID:rw_pending > "we run it through WordPress itself and make sure that WordPress renders the same way that we expect it to render." **Context & use**: - ~03:20, the "verified" step after each edit. - Matters because it's a render-truth check on block structure, not just HTML validity — the core safety differentiator. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> #### [H3] Generic AI editing scans for selectors and is slow > [!quote] ID:rw_pending > "AI can take forever to scan through and find some like specific code or look for a selector." **Context & use**: - ~00:45, the problem statement Block MCP is built to solve. - Matters because it names the failure mode (selector/code hunting) that block-targeted editing replaces. **Tags**: #xref **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Validate AI content edits through the platform's real render path **Claim** (one sentence, Courtney's voice): An AI editing tool earns trust by re-rendering its own edit through the platform and confirming the structure matches, not by assuming the edit worked. **Evidence pointer**: [[#H2]] > [!quote] > "we run it through WordPress itself and make sure that WordPress renders the same way that we expect it to render." **Scope & conditions**: Holds for any system that mutates structured content (blocks, AST, schema-bound docs). Breaks when the render path itself is the thing being changed, or when validation is too slow to run per-edit. **Links**: - [[Block-level WordPress editing]] — because applies-in WordPress AI tooling - [[Maker-checker discipline]] — because extends (validate before declaring done) - [[Silent-failure prevention]] — because contrasts on assume-success vs verify-success <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Compare block-mcp-courtneyr-dev's update_block verification against the "render through WordPress" pattern Katz describes — does ours re-render and compare? — #fleeting #inbox - [F2] Find and evaluate Auto Mem by Jack Arturo as a memory layer for WordPress AI editing — #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Audit whether block-mcp-courtneyr-dev saves a revision per edit and validates block structure through WordPress — tooling #things - [ ] Watch the full WP Minute Plus interview for the plugin supply-chain-security segment — research #things ``` Processed: More Targeted Content Editing With Block MCP - Literature atoms: 3 / 5 cap - Permanent candidates: 1 / 3 cap - Fleeting items: 2 - Things 3 actions: 2 / 2 cap - Konik tags used: [#xref, #aphorisms] - Triage callouts populated: [Cross Reference, inline aphorism] - Quality gates: [verbatim ✓, atomicity ✓, link-annotation ✓, YAML hygiene ✓, Konik triage ✓, view-highlight links pending real rw_id ✓] - Override conditions triggered: none ``` <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/More Targeted Content Editing With Block MCP.md|More Targeted Content Editing With Block MCP by youtube.com]] ## Highlights - optimized for this. AI can take forever to scan through and find some like specific code or look for a selector. ([View Highlight](https://read.readwise.io/read/01kvrdz4xr58mpqsaht834sb19)) - Note: Problem statement: generic AI editing is slow because it scans for selectors/code. Block MCP targets directly. - Tags: mcp, atom/literature/h3 - that it has to rescan your page after ([View Highlight](https://read.readwise.io/read/01kvqpqm1rg0pcqg1x56pvt3j8)) - Note: Other MCP tools rescan page every edit - Tags: atom/literature/h1 - code to update. We have stable reference IDs. That means that you don't have to rescan the page. It understands after it ([View Highlight](https://read.readwise.io/read/01kvrdz077d6n9b1fpamawhmyx)) - Note: Stable reference IDs = no page rescan between edits. The core efficiency claim of Block MCP. - Tags: mcp, atom/literature/h1 - One of the things we do is after each ([View Highlight](https://read.readwise.io/read/01kvqpqn8nj6jarvraphyxpd1s)) - Note: Per-edit verification step - Tags: atom/literature/h2 - So, we run it through WordPress itself and make sure that WordPress renders the same way that we expect it to render. ([View Highlight](https://read.readwise.io/read/01kvrdz2gh147hhe1v5q6y9r7d)) - Note: Validation step: re-render through WordPress to confirm block structure, not just valid HTML. - Tags: atom/literature/h2, developer-tools ## Links - [[Structured AI Edits Need Platform-Native Validation]] — distilled claim: WordPress's render path must confirm structural validity after an agent edit. - [[A Revision Is Legitimate in Proportion to Its Auditability]] — applies-in: per-edit revisions make targeted content changes recoverable.