wxctl ships an MCP orchestrator tool, 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 calls compose_start first, with the scenario:
compose_start {
  "use_case": "an HR chatbot that answers from the employee handbook and looks up records in the HR database"
}
It returns an ordered recipe plus the first artifact:
{
  "recipe": [ { "n": 1, "name": "identify", "tier": "config", "action": "…" },  ],  // 9 steps (config tier 1–5, deploy tier 6–9)
  "identify_prompt": "…a ready-to-run prompt containing your scenario…",
  "fix_loop": { "max_iterations": 3, "policy": "…" },
  "clarification": { "policy": "ask the user, never fabricate…" },
  "gates": [ "The plan must be error-free before apply…",  ]
}

The recipe

1

Identify

Run the returned identify_prompt with your model to list the resource kinds the scenario needs (resource_list.yaml).
2

Paths

Call compose_paths with the resource list to resolve dependencies and the recommended deployment path (paths.yaml).
3

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.
4

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.
5

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.
6

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.
7

Plan

Call wxctl_plan and review the diff. The plan must be error-free before you apply.
8

Apply

Call wxctl_apply with confirm: true, only after an error-free plan, to provision the resources.
9

Test

Call wxctl_test to run the config’s kind: test suite and confirm the deployment is green.
The first five steps are the config tier: pure compute that runs on every surface. The remote Worker (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.