Using OpenFactory Tools from an Agent Client

OpenFactory exposes account-scoped build, recipe, test, and VM operations through the Model Context Protocol. OpenClaw can be one client for that surface when it is configured to use a compatible remote MCP server. Treat any third-party skill as untrusted instructions: inspect it, pin its source, and review the permissions it asks the client to exercise.

What This Means

OpenClaw is an open-source AI agent framework that connects LLMs to external tools through skills. A skill is a structured document that tells the agent what tools are available, how to authenticate, and what workflows are possible.

OpenFactory exposes a MCP (Model Context Protocol) server for building images, inspecting recipes, reviewing tests, and working with owned VMs. The exact tool catalog is versioned and can change; discover it from the authenticated server instead of relying on this article's historical count.

An Agent That Builds Its Own Infrastructure

For most of its short history, an “AI agent with tools” has meant an agent that reads APIs: search the web, query a database, send an email. The interesting frontier is agents that produce infrastructure rather than just consume data: agents that can compile an operating system, boot it, and check that it works. That is a different kind of loop, and it only becomes practical when three things are true: the agent can describe what it wants in natural language, it can act through a stable tool interface, and it can observe the result well enough to decide what to do next.

MCP is what makes the second condition portable. Introduced by Anthropic in late 2024 and now an open standard maintained as an open protocol, MCP defines a way for clients to discover tools, read their schemas, and call them. Client support, authentication, transports, and policy differ, so verify the current client documentation. OpenFactory's build, test, and VM tools use this surface; a skill can add workflow instructions but does not add authorization or make model decisions trustworthy.

What the Agent Can Do

With an authenticated MCP client, an agent can request operations within the account and tool policy granted to its key. Keep these states distinct:

• Build: Create a custom Linux ISO from a recipe. Pick a base (Debian, Ubuntu, Fedora, openSUSE), add features (SSH, Docker, desktop, AI tools), configure users, networking, and security.
• Test. Spin up the ISO in a VM and request defined tests such as boot verification, package checks, network connectivity, service health, or supported CIS-aligned checks. A passing check is evidence for that check, not a compliance certification.
• Deploy: Create owned test VMs from eligible artifacts, take screenshots, and use available interaction tools. Screenshots can support visual review but do not prove every service, security control, or user workflow.
• Iterate: If tests fail, the agent can inspect results, modify the recipe, and rebuild. Templates and recipe validation catch issues before the build even starts.

Connect a Client Safely

Follow the current OpenFactory MCP integration guide. Mint a dedicated account-scoped key, store it outside prompts and source control, start with the smallest tool and resource scope, and revoke it when the workflow ends. If you add an OpenClaw skill, inspect its current files and security scan before installation; this article does not attest to a current public listing.

Example: “Build Me a Docker Server”

Tell your agent:

Build me an Ubuntu server with Docker and SSH. Add an admin user. Run tests to make sure it boots and Docker works. Give me the ISO download link.

A client can draft or validate a recipe, request a build after review, poll its status, request supported tests, inspect results, and retrieve an authorized artifact link. Tool names and schemas must be discovered from the current server. Require confirmation before actions that consume quota, alter state, expose an artifact, or create a VM.

Why MCP

MCP provides a shared protocol for exposing tool schemas and results to compatible clients. It can reduce client-specific integration work, but each client still has its own transport, authentication, approval, sandbox, and secret-handling behavior.

The OpenFactory MCP server runs at console.openfactory.tech/mcp-stream/mcp over Streamable HTTP. Authenticate with an API key (generate one in the console) or use session tokens for guest access. Prefer a terminal? The same operations are available through the openfactory CLI, which is handy when you want a scripted agent or a CI job to call the build engine without an interactive model in the loop.

Why The Feedback Loop Is The Point

A useful automation loop reads structured outcomes instead of assuming success. OpenFactory's current tool surface can report build status, progress, get_test_results returns structured pass/fail data with logs, and the desktop tools let the agent take a screenshot of an owned booted VM. A model can propose the next step; a policy or human reviewer should decide whether the evidence justifies another build or a deployment. The loop is describe, review, build, boot, observe, decide.

Recipe validation can catch schema errors and some unsupported combinations before a build starts. It cannot prove that every requested package exists, that the prompt intent was interpreted correctly, that the artifact will build, or that it is suitable for deployment. Preserve the conversation and recipe context during validation, then review the generated recipe and acceptance checks together.

Give The Agent A Sandbox, Not Your Server

An agent that can build and boot operating systems is powerful, which is exactly why it should run somewhere disposable. The image it produces is also the image it can be confined to: build a minimal VM with only the runtimes the task needs, run the agent inside it, and destroy it when the job is done. We make the full case for this in Designing a Safer Computer for an AI Agent. A VM adds a useful boundary only when mounts, credentials, networking, storage, devices, hypervisor policy, monitoring, and teardown are also constrained. Keep build and deployment authority outside the agent's sole control.

Quick Questions

• Do I need OpenClaw specifically?No. OpenClaw is one MCP client and the skill is convenient there, but any MCP-compatible agent can call the same OpenFactory tools, and the CLI works with no agent at all.
• What stops the agent from running up a bill?Validate first, and scope the agent's API key. Builds and test runs are explicit tool calls you can review in the console, so there is an audit trail of exactly what the agent asked for.
• Can it really tell whether a build worked?It can inspect defined test results and screenshots. Those observations can show that specific checks passed; they cannot prove the entire prompt was satisfied or certify the image. A reviewer should compare the recipe, logs, package inventory, test scope, and artifact checksum.

What's Next

The following are roadmap directions, not generally available commitments:

• Agent containers: Deploy entire teams of AI agents as lightweight containers inside a single VM, with inter-agent communication over local email.
• Build verification: workflows that can compare checksums, inventory evidence, and selected policy checks. Human security and compliance approval remains separate.
• Multi-agent workspaces: Org structures where each role (QA engineer, security auditor, DevOps lead) is an AI agent with its own persona and tool access.

Read the current MCP integration guide →