Build1 distinct publisher3 min readPublished
Doco's MCP server gives Claude Code a version fingerprint on every read and rejects any write built on a stale one. This is a first-party tutorial. The transferable part is the RFC 9110 precondition underneath it.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
The Claude connector gates that fail before your code runs: DNS, IPv4 and one Location header1 distinct publisher
product
A 2x LLM bill is not a bug report: token spend is an observability problem1 distinct publisher
build
255 tools, 71,929 tokens: the standing charge hidden in your MCP config1 distinct publisher
leadership
Anthropic's own telemetry: 93% of permission prompts approved. Budget for blast radius, not reviewers1 distinct publisher
The mechanism is two fields. A read returns the block's stable ID and a fingerprint for the document version it observed, and the tutorial's read-only prompt asks the model to report both [16][12]. The write sends that fingerprint back as an If-Match style precondition, and the server applies the change only while the selected representation still matches the condition the caller supplied [16][17]. If someone saved in between, the write does not land, and the instruction to the model is to stop and show the conflict [15]. Without the precondition the same sequence completes quietly: the agent reads version A, a teammate creates version B, and the agent writes an edit computed from A over the top of B [18].
The addressing requirement is what makes the read-only phase checkable at all. A paragraph should keep the same address when it moves [5], so you can ask for title, heading path, stable block ID and the exact evidence relied on, then open the document and look [12]. A confident answer with no address is one you get to re-derive by hand.
Count the requirements the author sets out for an editing contract and the weighting is clear. Four of the seven are about identity, version or write granularity: same address for a moved paragraph, a read that names its version, a stale write that fails visibly, and a small change that does not replace the whole document [5][19]. One is about search returning evidence rather than only a generated answer [5]. The author's finding is that a reliable boundary matters more than added context [20], and the list bears that out.
Doco is the author's own product, and the piece says to read it as a first-party tutorial rather than an independent comparison [2]. Two things would have to be true for the recipe to transfer to whatever store you already run. Your reads have to answer which block and which version. Your write path has to reject on mismatch rather than merge or last-write-wins. That is the lost-update protection the tutorial points at in RFC 9110 [17], a property of the protocol rather than any one vendor.
The connection details are ordinary and worth getting right anyway. Anthropic recommends HTTP for remote services and stdio for local processes, and the tutorial gives one command for each [6][7][8]. Keep the token out of committed configuration: Claude Code expands environment variables in project-scoped `.mcp.json`, so a shared config can reference a local secret without it landing in Git [9]. Run `claude mcp list`, then `/mcp` inside the session, and inspect the tools before asking the model to call them [10]. The Claude Code documentation warns that servers fetching external content can expose clients to prompt injection, and that knowledge-base text is data rather than trusted instruction [11]. That warning is the reason the write token is created with the minimum scope needed for one test on one disposable document [14].
Ranked by verification strength, evidence, and original report placement.
The tutorial is published on dev.to under the headline "Give Claude Code a Knowledge Base It Can Actually Edit", labelled Doco series, Article 11, Claude Code tutorial.
The author states that Doco is the product he is building and asks readers to treat the recommendation as a first-party tutorial rather than an independent comparison.
Doco is MIT licensed, and its stated relevant distinction is that browser users and API clients operate on the same collaborative documents.
The recommended approach is to connect a narrowly scoped MCP server that exposes structured search, versioned reads and block-level writes, starting read-only, verifying citations, and granting write access only after stale writes fail safely and every change remains visible to humans.
The article lists seven requirements for a useful editing contract: search should return evidence, not only generated answers; a paragraph should keep the same address when it moves; a read should identify the document version it observed; a write based on an old version should fail visibly; a small change should not require replacing the entire document; a person watching the document should see the same state; permissions should separate reading from writing.
Claude Code uses the Model Context Protocol to connect to external tools and data sources, and Anthropic recommends HTTP for remote services and stdio for local processes.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 30, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Standard checkable, product behaviour is the author's word
This splits cleanly in two. The precondition semantics come from RFC 9110 and the transport and prompt-injection advice from Anthropic's own documentation, so a sceptical reader can verify the reasoning without leaving public sources. The claims that Doco's reads carry a version fingerprint and that its protected writes reject stale ones have exactly one source: the person who wrote both the product and the tutorial.
No usage signal of any kind
The tutorial shows a hosted endpoint and a published CLI package existing, and stops there. No deployments, no users, no downloads, no third-party write-up — nothing that would let us say whether anyone besides the author has run this loop against a live handbook.
Restrained, with one unverified assertion doing real work
Barely stretched. The author declines the comparison he could have made, insists a safe demo must include a rejected write rather than a happy path, and warns against automatic retries — none of that is promotional behaviour. The residual gap is that the tutorial's whole payoff depends on Doco actually rejecting the stale precondition, and that is asserted rather than demonstrated.
Author sells the recommended server, and says so
As direct as commercial interest gets: the tutorial recommends the writer's own product, on his own series, with his own hosted endpoint and CLI in the commands. He labels it a first-party tutorial rather than a comparison, which is the honest move, but it does not change who benefits if you install it.
Coherent single voice, no corroboration
We can be fairly confident about what was said and why the pattern works; we cannot be confident that the implementation behaves as described. One publisher, one interested author, zero outside checks — but the reasoning is internally consistent and the transferable half is verifiable, so this is not a coin flip either.