← All posts

Building a remote MCP server that actually writes

I use Claude every day, and until recently every good thing it did for my business evaporated the moment I closed the tab. A chat is not a system of record. So I built one it could write to, and this is the part that was actually hard: making a remote MCP server that writes, not just reads.

The read-only trap

Most MCP servers people ship are read-only: list your files, fetch your data, answer questions about it. That's a demo. The moment a connector can create a task, move a deal, or publish a post on your behalf, the trust model changes completely — and so does the engineering.

Viite Business Studio's connector exposes eight tools (create_task, list_tasks, update_task, create_post, upload_asset, list_destinations, create_tracked_link, get_funnel_report) over a remote, OAuth'd MCP server. Three decisions made that safe enough to ship:

1. OAuth via better-auth, scoped per organisation. Claude never sees a shared credential. Every tool call carries the caller's own scoped token, and the server enforces per-tenant isolation the same way the human-facing app does — there is no separate, weaker code path for the agent.

2. Stateless Streamable HTTP, not a long-lived session. MCP's transport options include a stateful SSE mode that keeps connection state on the server. We didn't want a process pinned to a connection — Claude might call a tool, go away for an hour, and call another. Streamable HTTP treats each call as self-contained, which matches how an agent actually behaves: bursty, not continuous.

3. Publishing is armed by a state change, not a tool call. This is the one I'd defend hardest. create_post never publishes anything — it drafts a card. The card only goes live when it's moved to a reviewed status, either by a human on the board or by Claude when the user explicitly asks in a later turn. That means the dangerous action — something going out publicly under your name — is never a single tool invocation an agent can take unsupervised. It's a state transition on a resource you can see, inspect, and revert before it happens.

Why this matters beyond us

A connector that only reads is a toy. A connector that writes without a deliberate approval boundary is a liability waiting for a bad prompt or a bad day. The interesting design space for agentic tools right now isn't "can it take the action" — it's "where does the human's approval live, and can it be inspected after the fact." Ours lives on a kanban board. Yours might live somewhere else. But if you're building a write-capable MCP server, that boundary is the design decision that actually matters — everything else is CRUD.

If you want to see the write path yourself: Business Studio is free for one user — no trial, no card.

Start over?

Your current selections will be cleared.