What Is MCP? Model Context Protocol, Explained Through a Real AI Agent That Records Demo Videos

MCP, short for Model Context Protocol, is an open protocol that lets an AI application discover and call tools exposed by a separate server process. Instead of an AI model just generating text, MCP gives it a standard way to actually do things: query a database, call an API, or drive a browser.

That's the textbook definition. The more useful question is what it looks like when you actually build one. This post covers both: the general concept, and a real MCP server we built for Screenforge Director, our AI demo-recording service, which we verified working end to end with zero human clicks.

Key takeaways

MCP (Model Context Protocol) is an open protocol from Anthropic, documented at modelcontextprotocol.io, for connecting AI applications to external tools over a standard transport.
An MCP server doesn't think. It exposes callable tools; the AI client decides which ones to call, and why.
An AI agent plans, calls tools, observes results, and repeats the loop, rather than producing one static text response.
We built an MCP server for Screenforge Director and used it to generate three real demo videos entirely through tool calls from Claude Code, with no UI involved.
A separate agent loop actually drives the browser end to end. MCP just kicks that process off.

What is MCP (Model Context Protocol)?

MCP is an open protocol, created by Anthropic and documented publicly at modelcontextprotocol.io, that standardizes how AI applications connect to external tools and data sources (Model Context Protocol, 2024). It defines a common way for an AI client to ask a server what it can do, then call one of those capabilities with structured arguments and get a structured result back.

Before MCP, every integration was custom. If you wanted an AI model to check the weather, query a database, and send a Slack message, you wrote three separate glue layers, each with its own format. MCP replaces that with one protocol: any MCP-compatible client can talk to any MCP-compatible server, the same way any browser can talk to any website over HTTP.

In practice, that meant we didn't have to write a custom Claude Code plugin or a Cursor extension. We wrote one MCP server, and both clients, along with any other MCP-compatible tool, could use it right away, because they already speak the protocol.

What is an MCP server?

An MCP server is a process that exposes a defined set of tools, and sometimes resources or prompts, to any MCP client that connects to it. It runs separately from the AI model itself and communicates over a standard transport: stdio for local processes, or HTTP with server-sent events for remote ones (Model Context Protocol, 2024).

The server doesn't reason about anything. It answers two kinds of requests: list your tools, and run this tool with these arguments. All the thinking about which tool to call, and why, happens on the client side, inside the AI agent.

Director's MCP server, built with the official @modelcontextprotocol/sdk, is a thin adapter over Director's own REST API. It exposes a small set of operations a human developer would otherwise hit over HTTP as MCP tools an agent can call directly. No HTTP client code is required on the agent's side.

What is an AI agent, really?

An AI agent is a model that doesn't stop at one response. It plans a next action, calls a tool, reads the result, and decides what to do next, looping until the task is done or it needs more input. That loop (plan, act, observe, replan) is what separates an agent from a chatbot that only produces text.

A plain language model can describe how to book a flight. An agent can actually check availability, pick a seat, and submit the booking, because it has tools it's allowed to call and a loop that keeps it going until the job finishes.

Here's the distinction most explainers skip: the "agent" part and the "tool-calling" part are separate concerns. MCP solves tool-calling, giving the agent a standard way to discover and invoke capabilities. It says nothing about how the agent decides what to do next. That planning loop is a separate piece of engineering, and it's usually the harder half of the problem.

The case for building Director as an MCP server first

Screenforge Director takes a product URL and a one-sentence instruction, something like "record the onboarding flow," and turns it into a finished demo video. From day one, the intended caller wasn't a person filling out a form. It was an AI coding agent, already sitting in a developer's terminal, kicking off a recording as part of its own workflow.

That's an agent-first design choice. A polished web dashboard would help a human get comfortable with the tool. But if the primary caller is Claude Code or Cursor, what actually matters is a well-specified contract: clear tool names, clear inputs, clear outputs. An MCP server is exactly that contract, expressed in a format agents already know how to consume.

"If the primary caller is an agent, design for the agent first."

So instead of building a UI first and bolting on an API later, we built the REST API and the MCP server first. A UI, if it exists at all, would be secondary. Today, there isn't one. The MCP server is the interface.

How does an AI agent record a demo video through Director's MCP server?

Concretely, an agent like Claude Code calls a tool with a URL and an instruction. Director's server accepts the job, starts a browser session, and returns a job ID immediately, the same pattern any async REST API would use, just expressed as an MCP tool call instead of an HTTP request.

The tools Director exposes

Director's MCP server exposes a small set of tools, mirroring its REST endpoints one for one: submit a demo request, check on a job, and fetch the result once it's ready. Nothing about the underlying work changes. The tools are just a direct MCP-shaped door into the same API a human would otherwise call with curl.

What a real session looked like

We tested this by having Claude Code drive the entire process itself: submit a demo request, poll for status every few seconds, then fetch the result once the job finished. We ran this against several different targets, and in every case a finished MP4 came back with no human touching a browser, a form, or a UI at any point.

Why does that matter? Because the agent wasn't filling out a web form asking Director to record something. It was calling a tool, waiting, and calling another tool, exactly the same loop it would use to read a file or run a shell command.

What happens inside the browser while the agent is "recording"?

The MCP layer only handles the request and the eventual result. It has nothing to do with how Director actually operates the browser. That work happens in a separate agent loop that drives a real browser, clicking, typing, and scrolling the way a person would.

The planning loop

Director structures this as a graph of steps, observe, decide, act, so the record-and-decide cycle stays organized from start to finish, instead of relying on one long, unstructured prompt.

The acting loop

At each step, the agent looks at the current screenshot and page state, decides the next action, performs it, then observes what changed. If a click didn't do what was expected, it replans and tries something else, the same grounded, iterative approach a person uses when a webpage doesn't behave the way they expected.

Once that loop finishes, the recorded session gets handed to Director's render engine, a separate system entirely. It adds the auto-zoom on click clusters, the animated cursor, and the keyboard captions that turn a raw screen recording into a demo video worth watching.

What have we verified, and what's still local-only?

We've verified the whole loop end to end, but it's worth being precise about where things stand today. Director's MCP server currently runs over stdio, meaning it's a local process an agent connects to directly. There's no public remote MCP endpoint yet, and there's no web dashboard for a human to click through instead.

That's a deliberate sequencing choice, not an oversight. In our experience, building the agent-facing contract first, and proving it actually works end to end, matters more than a UI that nobody actually using the tool would touch. Making the server publicly reachable is a separate, later step.

What we verified: several demo videos, generated entirely through MCP tool calls from Claude Code. No human touched a UI at any point.

Frequently asked questions

What is MCP in simple terms?

MCP (Model Context Protocol) is an open standard that lets an AI application call external tools through a consistent interface, instead of every integration needing its own custom code. An AI client asks a server what tools it has, then calls one with structured arguments and gets a structured result back (Model Context Protocol, 2024).

Is an MCP server the same thing as an API?

Not quite. An MCP server usually wraps an existing API. It exposes the same functionality in a format AI clients already understand: named tools, structured inputs, and structured outputs, instead of requiring the agent to hand-write HTTP request code for every different service it calls.

What's the difference between an MCP server and an AI agent?

An MCP server exposes tools; it doesn't decide anything on its own. An AI agent is the piece that decides which tool to call, when, and why, then loops through calling it, reading the result, and deciding the next step. MCP standardizes the tool-calling half of that relationship, not the planning half.

Do you need Claude Code or Cursor specifically to use an MCP server?

No. Any MCP-compatible client can connect to any MCP server, since both sides speak the same protocol. Claude Code and Cursor are two common examples of MCP clients developers use today, but the protocol itself isn't tied to either one specifically.

Does Screenforge Director have a public MCP endpoint or web UI yet?

Not yet. Director's MCP server currently runs locally over stdio, and there's no public remote endpoint or web dashboard. The verified, working interface today is the MCP server itself, tested by having Claude Code generate real demo videos entirely through tool calls, with no human interacting with a UI.

How does an AI agent actually click and type on a real webpage?

Under Director's hood, an orchestrated planning loop drives a real browser. At each step, it looks at a screenshot, picks a click or keystroke, performs it, observes the result, and replans if the page didn't respond as expected.

The takeaway

MCP is a plumbing decision as much as it's an AI decision. It's what let us build one demo-recording engine and make it callable from any agent that already speaks the protocol, without writing a bespoke integration for each one.

The bigger lesson for us was about sequencing. We built the MCP server and proved it end to end, several real demo videos, zero human clicks, before spending any time on a UI most of our actual callers won't touch. If your primary caller is an agent, design for the agent first.