Letting an agent write to my production CMS

The slowest job on the content platform I run is authoring a review end to end. Create the record, fill seventy-odd structured fields, write the narrative blocks, upload and wire the screenshots, publish. Every review follows the same shape, which is exactly what makes it miserable and exactly what makes it a good candidate to hand off. The worry people lead with is quality. Will the agent write something embarrassing? That is the easy half. A draft is reviewable, and a bad draft costs nothing but the time it takes to read. Authoring means writing to production, though, and that is a different animal. An agent with write access to a live CMS is not a drafting tool. It is a second admin who never sleeps, never gets bored of the tedious fields, and will work straight through the backlog without ever wondering whether the first record came out right. So the question was never whether an agent could edit the site. It was: what does it authenticate as, what enforces the rules when it writes, and can I reconstruct afterwards what it did. Why a tool server and not a script I weighed three shapes for the write path. One-off REST scripts are the fastest thing to start and the worst thing to own. Each one re-implements whatever slice of the validation rules it happens to need, they do not compose, and nothing tells you later which of them check anything at all. Browser automation is more tempting than it looks, because driving the real admin UI inherits every rule the UI enforces for free. It is also slow, brittle against any markup change, and hands you a screenshot where you wanted a result. I built an MCP server instead. The tools are primitives (get a listing, update a listing, upload an asset, replace a page's blocks) and the agent decides how to sequence them. That was the part worth paying for: I did not have to anticipate the workflows, only the verbs. Roughly forty tools now cover the entity types the CMS manages, and none of them encode a workflow. One server, two t