The Hidden Cost of Content Ops, and How MCP Made Automating It Boring

Every video or course platform eventually runs into the same quiet cost center: someone has to write the titles, descriptions, tags, and chapter markers for every piece of content that goes live, and someone has to answer “which lesson covers X” support tickets from people who don’t want to search. None of it is hard work. All of it is constant, and it scales linearly with content volume in a business where content volume is the whole point.

The setup

The platform: a few thousand video lessons across a few hundred courses, growing every week. Two content managers spent a good chunk of their time on exactly the tasks above, not because the company lacked better things for them to do, but because the work had to happen somewhere, and it was never worth automating on its own.

The instinct is to reach for “let’s use ChatGPT to draft descriptions.” The part that actually matters is less about the model and more about how it gets access to the platform’s real data — the transcript, the existing metadata, the support history — without turning into another integration nobody wants to maintain.

Why MCP, specifically

This is the part worth being precise about: an MCP (Model Context Protocol) server is a small, standard interface that exposes a system’s data and actions to an AI agent in a way the agent can discover and call directly, instead of every integration being a bespoke script. For content ops, that meant one MCP server sitting in front of the video platform (list videos, fetch a transcript, read existing tags, propose an update) and a second in front of the helpdesk (read a ticket, search past resolved tickets, draft a reply). The agent talks to both through the same protocol; neither system had to be rebuilt to support it.

The practical benefit isn’t philosophical — it’s that adding a third data source later (say, the CMS that manages the marketing site) means writing one more MCP server, not renegotiating how the whole pipeline works.

The one thing that almost went wrong

Worth being specific about, because it’s the kind of failure mode that’s easy to miss until it happens: the first version of the tagging step let the agent pull tags from a general list it generated itself, instead of the platform’s existing tag taxonomy. It “worked” in the sense that the tags were reasonable — and completely fragmented the site’s existing category structure, because “backend development” and “back-end engineering” are the same tag to a person and two different ones to a search filter. The fix was mechanical once it was diagnosed: the agent’s MCP tool for tagging only exposed the existing taxonomy as valid options, full stop — no freeform tags allowed, ever. That constraint did more for output quality than any amount of prompt tuning did.

What the agent actually did

Drafting descriptions and tags. For every new video, the agent pulled the transcript, drafted a title, a two-sentence description, and five to eight tags, then opened it as a pending item in the CMS — never published automatically. A content manager reviewed and approved in bulk, editing maybe one in five drafts before publishing. The work shifted from writing from a blank page to editing a reasonable first draft, which is a meaningfully faster task.

Chapter markers from the transcript. Instead of someone scrubbing through a 40-minute video to mark where each topic starts, the agent proposed timestamps based on topic shifts in the transcript. Reviewers adjusted the occasional marker that landed a few seconds off — far faster than creating them from nothing.

Support ticket triage. For “which lesson covers X” tickets — a genuinely large share of the queue on a course platform — the agent searched existing video metadata and transcripts, drafted a reply linking the right lesson and timestamp, and queued it for a human to approve and send. Tickets that didn’t match anything with confidence were left alone for a person to handle from scratch, with no draft attached — a deliberate choice, since a wrong guess presented confidently is worse than no guess at all.

What it saved, and what it didn’t

The two content managers went from spending roughly half their week on descriptions, tags, and routine tickets to spending something closer to an afternoon, reviewing and editing drafts rather than producing everything from scratch. That’s the honest shape of the win: not “content ops became free,” but “the first 80% of every repetitive task stopped requiring a person to start it.”

What didn’t change: anything touching brand voice for a flagship course, any support conversation involving a refund or a complaint, and final approval on everything the agent touched. The agent drafted; a person always decided what shipped. That boundary is also what made the two content managers comfortable with the system instead of threatened by it — their job shifted from producing to curating, and curating well is a skill that took them longer to build than writing tags ever did.

Rolling it out without it feeling like a threat

The technical part was the easy half. The part that actually determines whether something like this survives contact with a real team is how it’s introduced. Framing it as “here’s a tool that drafts your first pass, you still decide what ships” landed very differently than “here’s what’s automating your job” would have — because it’s also just a more accurate description of what the system does. Content managers who reviewed drafts for a few weeks tended to trust the system more over time, not less, once they’d seen it consistently defer to a human instead of quietly overriding one. That trust is fragile in the other direction too: one confidently-wrong auto-published change would undo weeks of it, which is exactly why nothing published without a person approving it first.

The takeaway

The interesting lesson isn’t “AI can write product descriptions” — everyone already believes that. It’s that the unglamorous integration work of wiring an agent safely into the systems that already hold the real data is the actual project, and MCP is what turns that from a bespoke, brittle integration into something closer to plumbing. The busywork disappears. The judgment calls don’t, and they’re not supposed to.