# The Safest First MCP Workflow Is a Draft Queue, Not an Autonomous Agent > Source: > Published: 2026-08-16 16:40:58+00:00 Most small businesses do not need an autonomous agent. They need the next customer reply drafted, the right product notes found, and a human who can still sleep knowing nothing weird went out overnight. That is how I would start the first useful MCP project. The tempting demo wires the agent to CRM, inbox, calendar, WordPress, analytics, and payments. It looks powerful. It also creates a large surface for wrong tool choices, accidental writes, duplicate sends, and questions nobody can answer later: For a small team, the safer start is a **draft queue**. The agent researches and prepares a proposed action. A person approves it. Only then does a narrow workflow perform the side effect. Less spectacular than an autonomous agent. More likely to survive a real Monday. The Model Context Protocol gives apps a standard way to expose tools to language models. A tool has a name, description, and input schema. It can query a database, call an API, or run a computation. That standardisation helps. It does not decide which tools an agent should see, or which calls may change state. Those are application decisions. Treat every MCP tool as one of two things: Category one is a good pilot surface. Category two stays behind an explicit approval boundary until the workflow has earned trust. The protocol can make integrations interoperable. It cannot make a sloppy permission model safe. Imagine a five-person agency receiving enquiries from a website form. The first agent version needs only four tools: `search_services` — read the approved service catalogue`find_faq` — retrieve answers from maintained FAQs`lookup_enquiry` — read one enquiry by internal ID`create_reply_draft` — write a proposed reply into an approval queueNotice what is missing: no send-email tool, no unrestricted filesystem tool, no “read every customer,” no inventing prices from a private spreadsheet. A worker can follow a boring, inspectable sequence: `needs_review` .The model earns its keep by removing repetitive search and first-draft work. Approval is a state transition, not a polite line in the system prompt. A useful intermediate stage is **shadow mode**. The agent runs on real or representative requests but cannot create even a draft in production. It writes proposed tool calls and outputs to a review log. A human compares that with what they would have done. For two weeks, track simple measures: That gives evidence instead of vibes. It also surfaces missing business rules. Repeated edits often mean a documentation problem, not a model problem. Only after shadow results look acceptable should the workflow create `needs_review` drafts. Automatic side effects come later. Do not bury approval in a chat transcript. Give it a small, durable record. A draft queue entry might look like: ``` { "id": "reply-2026-0713-0042", "request_id": "enquiry-1842", "status": "needs_review", "proposed_action": "send_email", "recipient": "customer@example.test", "body": "A human-readable draft goes here", "source_refs": ["services/websites", "faq/migrations"], "created_by": "agent", "approved_by": null, "created_at": "2026-07-13T09:30:00Z" } ``` Schemas will vary. The fields that matter are action, scope, source references, and state. Approval should mean “approve this exact proposed action,” not “the agent may now freestyle with email.” When a reviewer edits the draft, record that too. Edits are feedback and audit trail. The final send step should be a narrow integration with boring validation. It accepts a queue ID, loads the approved record, checks status is `approved` , confirms recipient and body have not changed, and sends once. It should reject: Idempotency matters. If a network timeout hits after the provider accepted the email, a blind retry can double-send. Store a provider message ID or another durable operation key and resolve the previous attempt before sending again. This is ordinary workflow engineering. That is the point. MCP should connect the agent to a workflow; it should not replace the workflow’s invariants. A local model (for example via Ollama) can be a good fit for drafting and classification when you want less data movement or lower recurring API cost. Ollama’s tool-calling support makes structured tools practical, and its MCP examples point the same way: reason over a controlled tool surface. “Local” is not the same as “private by default.” The moment a tool hits a cloud CRM, email provider, hosted observability service, or external search API, selected data leaves the machine. Logs can leak data too. The useful question is not “is the model local?” It is: What is the minimum information this step needs, and which system is allowed to receive it? Pass an enquiry ID rather than an export. Return the relevant FAQ paragraphs rather than the whole document store. Redact secrets before logging model input. Keep high-risk tools out of the worker’s catalogue entirely. **Week 1: define the boundary.** One repetitive workflow. List read tools, draft output, approval owner, and unacceptable actions. **Week 2: build shadow mode.** Capture proposed tool calls and drafts without writing to production. Build a small evaluation set from representative, sanitised requests. **Week 3: add the approval queue.** Let the agent create reviewable drafts. Add source references, statuses, expiry, and an audit record. **Week 4: automate one narrow side effect.** Lowest-risk approved action only. Validate exact inputs, add idempotency, measure failures as carefully as successes. At the end, the question is not whether the agent looked clever. It is whether staff trust the queue enough to use it, whether corrections are falling, and whether every side effect can be explained afterwards. MCP is interesting because it gives agents real capabilities. That means the first design decision should be about control, not tool count. A draft queue is a useful middle ground: the agent does tedious preparation; people keep authority over irreversible changes. Shadow mode creates evidence before risk. Narrow tools and durable state make failures diagnosable. If that workflow becomes reliable, add one capability at a time. If it does not, you learned something without handing an untrusted process the keys to the business. The best first MCP workflow is rarely an autonomous agent. It is a well-labelled queue of work a human can understand, approve, reject, and replay.