A creative automation surface becomes hard to trust when the app, internal copilot, and external agents all use different implementations. A button works one way, chat works another way, and an integration bypasses the rules entirely.
Storyloom starts from one typed Actions registry in its core engine. Direct UI actions call it. The copilot plans work around it. The MCP package projects the same registry as tools for an external Model Context Protocol client.
One action contract
The registry defines validated inputs and a common execution path. Provider adapters sit behind a MediaProvider contract, while the job runtime handles submission, polling, retries, and logging. That keeps model-specific details out of the canvas interaction.
When an MCP client calls a Storyloom tool, the request becomes a call to the deployment's action API. It follows the same key resolution and provider path as work initiated in the browser. MCP is another caller, not a second engine.
Why the board still matters
Agent control does not remove the visual workspace. The board is where results are placed, compared, and edited. An external agent can initiate a sequence, but the output remains part of the same creative surface a person can direct.
This is useful for repeatable setup work. An agent can create a planned group of artifacts, label sections, and return a board ready for review. The human can then rearrange, reject, remix, or continue with direct controls.
Keyless development
The MCP server can point at a local Storyloom deployment. With no provider keys, the deployment uses the same deterministic placeholder runtime as the web app. That makes tool discovery and workflow development reproducible without spending against a provider account.
For real generation, provider keys can be supplied to the MCP process and forwarded with each action request, or configured on the deployment. The same BYOK caveats apply: the key reaches the Storyloom server and the selected provider.
A factorable core
The larger design goal is not “put chat everywhere.” It is to keep creative operations factorable. A new shell can reuse the engine without reimplementing its provider logic. A new model adapter can appear behind the existing action surface. A creator can choose whether the next action comes from a button, Storyloom's copilot, or an external agent.
That architecture is visible in the repository rather than described as a future platform. Explore the packages on the open-source page, then follow the setup in the Storyloom README to connect an MCP client.