wxctl ships an MCP orchestrator tool, compose_start, that turns a single sentence 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. 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 use-case sentence: 
compose_start {
  "use_case": "HR chatbot with employee handbook and database access"
}
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 sentence…",
  "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 use case 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 use case 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

compose_start is registered on the local stdio server (wxctl mcp serve) and the remote Worker (mcp-remote), and returns byte-identical recipe content on both — so an agent gets the same guided flow whether it talks to your local binary or the hosted endpoint.

​
Next steps

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.