Build the same calculator-weather-agents example without writing config.yaml by hand. You describe the scenario in one sentence, then IBM Bob drives wxctl mcp serve to compose the config, scaffold the tools, plan, apply, and test, then tear it all down. The deployed result is identical to the Declarative path: one knowledge base, two Python tools, two agents, and four tests. This page documents the flow proven live on watsonx Orchestrate. To wire other MCP clients (Cursor, Claude Desktop, or your own agent), see MCP clients.

​
Prerequisites

  • A prebuilt wxctl binary on your PATH. See Installation.
  • A watsonx Orchestrate profile. Every resource is a watsonx Orchestrate resource, so the profile needs one watsonx_orchestrate block. See Profiles & credentials.
  • IBM Bob installed. Bob is the MCP client that runs the flow.
  • .bob/mcp.json wiring Bob to wxctl mcp serve. Create it in the project directory:
.bob/mcp.json
{
  "mcpServers": {
    "wxctl": {
      "command": "wxctl",
      "args": ["mcp", "serve"]
    }
  }
}
Replace "wxctl" with the absolute path to the binary if it is not on Bob’s PATH. The working directory must be a Bob trusted folder so Bob can read and write files there. To wire Bob for every workspace, put the same block in ~/.bob/mcp_settings.json instead.

​
Write the scenario

Start from an empty project directory that holds only use-case.txt with the scenario:
use-case.txt
A calculator agent that does arithmetic with a Python tool and answers IBM
history questions from a knowledge base, plus a weather agent that reports
city weather and delegates any math to the calculator agent

​
Run it interactively

Launch Bob in the project directory: 
bob
Give Bob one instruction: 
Read use-case.txt and take that scenario end to end with the wxctl MCP tools:
start with compose_start and follow its recipe to generate, validate, and
deploy the config, run the tests, then destroy everything. Report each stage.
Bob calls compose_start first, which returns the ordered recipe and its guardrails, then works through the stages below. Approve each MCP tool call as Bob composes, validates, scaffolds, plans, applies, tests, and destroys. Apply and destroy pause for your confirmation (the server gates them with confirm: true); the read-only steps and wxctl_test run without a gate.

​
Run it headless

For an unattended or CI run, Bob Shell takes the same instruction in one shot: 
mkdir demo && cd demo
echo "A calculator agent that does arithmetic with a Python tool and answers \
IBM history questions from a knowledge base, plus a weather agent that reports \
city weather and delegates any math to the calculator agent" > use-case.txt

bob -p "Read use-case.txt and take that scenario end to end with the wxctl MCP \
tools: start with compose_start and follow its recipe to generate, validate, and \
deploy the config, run the tests, then destroy everything. Report each stage." \
  --yolo
--yolo approves the tool calls and file writes a non-interactive session would otherwise refuse, so the generated config.yaml and tool sources land in the current directory. The confirm: true gate on apply and destroy still holds inside the server, as does the error-free-plan-before-apply rule. To let an unattended agent explore with no possibility of mutation, wire the server with --read-only in args instead.

​
The stages

Bob works through the compose_start recipe in order:
StageToolsWhat happens
Recipecompose_startReturns the ordered steps, the fix-loop policy, and the plan-before-apply gate
Generatecompose_paths, compose_promptBob’s model writes config.yaml: a knowledge base, two Python tools, two collaborating agents, and a generated kind: test suite
Checkwxctl_validateSchema and reference checks; an invalid config returns a fix prompt (at most 3 iterations)
Scaffoldcompose_scaffoldMaterializes the tool source stubs on disk; Bob fills in the implementations and the knowledge-base document
Previewwxctl_planThe dependency-ordered create plan, which must be error-free
Deploywxctl_apply (confirm: true)Creates the resources
Provewxctl_testRuns the generated tests against the live deployment
Resetwxctl_destroy (confirm: true)Tears everything back down
wxctl_apply refuses to run until a preceding wxctl_plan succeeds, so Bob cannot skip the preview. This is that run, fast-forwarded: Bob generates the config and the implementations, deploys, proves it with the tests it wrote, and tears it all down.

​
What you deployed

The Reset stage already tore the resources down, so nothing is left running. Along the way Bob deployed and tested the identical result of the Declarative path:
  • 1 knowledge base, grounded in the IBM company-history document.
  • 2 Python tools, a calculator (add / multiply / divide) and a weather lookup (mock city forecasts).
  • 2 agents, a Calculator Agent (calculator tool + knowledge base) and a Weather Agent (weather tool) that delegates arithmetic to the Calculator Agent.
  • 4 tests, covering a calculation, an IBM-history answer, a Tokyo forecast, and delegation.
Same five resources, same four tests, composed from one sentence instead of hand-authored.

​
Next steps

Build it by hand

The other way to build this: write every file yourself, then plan, apply, and test.

MCP clients

Wire wxctl into Bob, Cursor, or a hosted config-authoring Worker.

Generate a config from a scenario

The compose_start recipe in depth: identify, generate, plan, apply, test.

Resource kinds

Every kind the discovery tools can list and explain.