How structured context, approved tools and guardrails allow AI to move from explaining a video platform to operating it safely.

By Paul O’Donovan

A few months ago, I built a streaming platform without writing code.

The most interesting part was not that Claude generated the code. It was why the process worked. The MK.IO documentation had been structured so that both people and machines could understand it.

That experiment showed how documentation can turn AI from a conversational assistant into a practical implementation tool.It also raised the next question: what happens when AI can operate the platform directly?

From documentation to context

One of our video platforms has roughly 10,000 pages of documentation, covering everything from individual API endpoints to complete operational workflows.

That depth is valuable, but it creates a practical challenge. Even excellent documentation requires users to know what to search for, understand the terminology and connect information spread across different sections.

We started by bringing the documentation together, restructuring it and making it more consistent.

Through Model Context Protocol, or MCP, an AI model can access this information as structured context rather than simply searching through thousands of pages.

It can understand individual API endpoints, but also the workflows, dependencies and sequencing that turn those endpoints into a working video service.

As George Hampton, our Developer Advocate, puts it: “Tell AI, ‘Get this video from A to B.’ It can handle the complexity. The challenge is making it reliable.”

Context is not execution  

With the right context, an AI model can write a script, assemble API calls or generate an application.

That is what Claude did when I built my streaming platform.

It is also where inconsistency can creep in.

Ask an AI model to solve the same problem twice and it may take a different route each time. That is perfectly acceptable when experimenting. It becomes less charming when the model is creating billable resources or changing a live service.

A well documented API is necessary, but it is not enough.If the model still has to choose the endpoints, combine them into a workflow and generate fresh code, it is inventing the execution path each time.

From generated code to approved actions

The next layer is a defined set of tools between the AI agent and the underlying APIs.

These tools describe the actions the agent is allowed to perform, the inputs each action requires, the validation that must take place, how errors are handled and what permissions apply.

They must also remain aligned as the platform and its APIs evolve.

This is not a one-time wrapper around an API. It is product work.

Once this layer is in place, the agent stops creating a new implementation every time. Instead, it selects from a set of known and tested actions.

George has been working on exactly this.

In one recent test, an AI agent created a multiview event in around two minutes. It did not write code or construct cURL commands. It selected and used the tools it had been given.

The real value is not that the process took two minutes.It is that trying something becomes much easier.

Making complex platforms easier to explore

Video platforms contain specialist terminology, complex dependencies and a large number of configuration choices.

That creates a high barrier for someone exploring an unfamiliar workflow. Before testing an idea, they may need to understand the product, find the correct documentation, identify the relevant APIs and work out how all the pieces fit together.

AI can absorb some of that complexity and give more people a practical route into the platform.

Teams can test ideas, explore unfamiliar workflows and discover capabilities they did not know were already available.

It does not remove the need for engineering. It allows teams to learn before committing engineering time and budget to a large integration project.

Commercially, that matters.

Customers can discover more of the value already available within the platform. They can test ideas sooner, validate workflows before investing in them and avoid unnecessary custom development.Better documentation no longer just explains how the platform works. It helps customers get more value from it.

Guardrails are part of the product 

Giving an AI agent the ability to act creates an obvious concern.

What happens when it does the wrong thing?

Video resources cost money. Live services have viewers. An agent that creates 1,000 resources when you wanted five has moved beyond being an amusing chatbot problem. It has become an expensive operational problem.

This is where guardrails become essential.

Instead of choosing from every possible API call and inventing its own route, the agent selects from a limited set of approved actions.

That is a much smaller and more predictable problem.

Fewer choices mean fewer opportunities to be wrong. Inputs can be validated before anything happens. Permissions can limit what each user or agent is allowed to do. Cost and resource limits can be applied. Potentially destructive actions can require confirmation.

This approach should also reduce the amount of reasoning and computation required. Selecting an approved action is simpler than designing an entire workflow and generating fresh code.

Fewer mistakes also mean less rework, lower operational risk and fewer unnecessary resources being created.

The agent still understands the request and decides which action is appropriate.It simply does not invent how that action should be executed.

The next role of documentation

The direction is becoming clear.

First, make documentation understandable to both people and machines.

Then give AI structured tools that allow it to perform approved actions, with the validation, permissions and guardrails needed to make those actions predictable.

We are taking this direction across our wider portfolio. Some elements are available today. Others are prototypes or active areas of exploration. We will be showing more of this work at IBC.

This is not about replacing developers, operators or solution architects.

It is about making their knowledge easier to access and their platforms easier to use.

Documentation used to explain how to use the product.Increasingly, it will also define how AI agents can use it safely.

---

Explore the documentation
Explore MCP documentation to see how AI agents can access structured context today.