compose_start, that turns a plain-language scenario
into a deployed configuration. Point any MCP client (Claude Code, Cursor, Claude Desktop, or your
own agent) at a wxctl mcp serve server, and the agent drives the whole flow: identify the
resources, generate the YAML, validate and fix it, plan, apply, and test, asking you for anything
it can’t infer rather than fabricating it.
The server stays model-free. compose_start is pure compute: no retrieval, no server-side
generation, no credentials. Your agent’s own model does every generation pass.
One call to start
The agent callscompose_start first, with the scenario:
The recipe
Identify
Run the returned
identify_prompt with your model to list the resource kinds the scenario
needs (resource_list.yaml).Paths
Call
compose_paths with the resource list to resolve dependencies and the recommended
deployment path (paths.yaml).Generate
Call
compose_prompt with the scenario and paths, run the returned prompt with your model,
and save the output as config.yaml. If the model returns a kind: clarification_request
instead, ask the user and re-run; the recipe never fabricates account ids, CRNs,
credentials, or resource names.Validate and fix
Call
wxctl_validate on the config. If it returns valid: false, it also returns a
fix_prompt scoped to the failing kinds: run it, regenerate, and re-validate. The recipe
bounds this loop to 3 iterations. Pass skip_post_validate: true in the config-tier
flow to skip scaffold-dependent checks.Generate tests
Call
compose_prompt with test_config: true on the validated config, run the returned
prompt with your model, and append the resulting kind: test documents to config.yaml.
This closes the config tier: the steps every surface can run, including the
FS-/network-free mcp-remote Worker.Scaffold
Now in the deploy tier (needs a local filesystem + profile): call
compose_scaffold to
materialize source stubs in-cwd (or config_unchanged: true when the config has no source
files), fill them in with the implementation prompts, then re-validate the source-bearing
config (this time without skip_post_validate) before you plan.Apply
Call
wxctl_apply with confirm: true, only after an error-free plan, to provision the
resources.mcp-remote) stops there with a validated
config.yaml and its kind: test suite, and hands off to a local surface for the deploy
tier (scaffold → plan → apply → test), which needs a filesystem and a live profile.
Every surface returns the same full nine-step recipe by default. A config-only caller can opt
into just the authoring slice with compose_start { "max_tier": "config" } to get steps 1–5;
omit max_tier (or pass "deploy") for all nine.
wxctl_apply requires both confirm: true and a preceding error-free wxctl_plan. The
recipe’s apply step and the tool’s own description state this gate, so an autonomous agent
never applies an unreviewed plan.Both surfaces
The compose orchestrator is registered on the local stdio server (wxctl mcp serve) as
compose_start and on the remote Worker (mcp-remote)
as wxctl_compose_start, and both return byte-identical recipe content, so an agent gets the
same guided flow whether it talks to your local binary or the hosted endpoint.
Next steps
Generative quickstart
Watch IBM Bob take this exact flow end to end, interactively and headless.
Worked example
Declare a tool, an agent, and a test by hand, then plan, apply, and test.
Resource kinds
Every kind wxctl supports, with fields and endpoints.

