Starting constraint
An editorial team produced multilingual long-form content. They wanted AI assistance for drafting and translation, but they refused two things: opaque cost, and unsupervised publishing. Both are reasonable refusals.
The brief was: give us AI tooling that we can audit, that does not surprise us with a five-figure bill, and that never publishes anything a human did not approve.
Why MCP and not direct API calls
Direct calls to Anthropic or OpenAI from WordPress code would have worked. They would also have spread credentials across plugins, leaked cost per feature, and made audit unrealistic.
MCP gave one boundary: the editorial team's WordPress install talks to one MCP server, the MCP server talks to model providers, and every tool call is typed, logged, and scoped.
Tool design
Every tool was typed with Zod and named for the editorial action it represented: suggest_outline, draft_section, translate_to_locale, evaluate_against_voice. Each tool had a clear input schema, output schema, and side-effect declaration.
Tools that produced content never wrote directly to wp_posts. They wrote to a draft queue. A human approved before publishing.
Cost control by design
Per-user, per-tool, and per-day budgets were enforced at the MCP boundary, not at the API call. When a user hit a cap, the next call returned a budget exhausted response and the editorial UI told them so. No silent overruns.
The same boundary surfaced cost reports per locale, per topic cluster, and per tool. Finance had a single dashboard.
Outcome bands
Exact numbers are confidential. Publishable: editorial throughput improved on translation tasks, time-to-first-draft dropped on long-form briefs, and cost stayed inside the agreed budget every month thanks to the hard caps.
The reusable lesson: AI in editorial works when the boundary is typed and the budget is enforced, not when the prompt is clever. Most failed AI editorial tools fail at the boundary, not at the model.