How wxctl compares

wxctl is a declarative tool for IBM product resources, not general infrastructure. It borrows the plan-before-apply ergonomics of infrastructure-as-code but targets a different layer and resolves identifiers differently. Use it alongside an IaC tool, not instead of one.

​

At a glance

​

When to use which

wxctl and an IaC tool work at different layers, so most teams run both. The IaC tool stands up the platform, then wxctl declares the product resources on top of it. Use wxctl to provision and wire IBM product resources across services: watsonx Orchestrate agents and tools, watsonx.ai deployments, watsonx.governance monitors, watsonx.data catalogs and engines, Cloud Object Storage, IBM Concert compliance and resilience posture, IBM Instana observability, and IBM Planning Analytics cubes and processes. Use Terraform or Pulumi for the infrastructure underneath: the cluster, networking, IAM, and the account scaffolding wxctl runs on. Pulumi suits teams who prefer a general-purpose language over HCL. Use Ansible to configure servers or run procedural deployment steps on hosts.

​

What wxctl borrows, and what it does differently

wxctl shares the declarative model and a plan preview with Terraform and Pulumi. The differences are deliberate:

• No state file. Your config is the desired state; the live API is the actual state, read fresh each run. Nothing to lock, share, or let drift.
• Late-bound identifiers. References resolve at run time, so one config is portable across environments with zero embedded IDs.
• Product-resource graph. wxctl derives a dependency DAG from ${kind.ref_name} references and resolves each ID into the exact format the consuming IBM API expects.

​

IBM product MCP servers

IBM publishes MCP servers that connect an AI agent to a single product’s API, one server per product. They complement wxctl rather than replace it, and wxctl ships its own MCP server built on the same engine. A product MCP server turns that product’s API into tools an agent calls one at a time. The agent picks the order, reads each identifier out of one response, and feeds it into the next. That fits interactive, read-heavy work inside one product, but it gives you no preview before a change, no idempotency, and no record of desired state. Re-running the same conversation is not guaranteed to reach the same result, and wiring resources across products means the agent stitches calls across several servers by hand. wxctl works from a declarative config of the end state instead. It plans before it applies, builds one dependency graph across products, resolves every ${kind.ref_name} for you, and converges to the same result on every run. The config is a file you commit, review, and diff. wxctl’s own MCP tools wrap that pipeline, so an agent that drives wxctl still gets the plan preview, the idempotent reconcile, and the cross-product graph. Use a product MCP server to query or explore one product conversationally. Use wxctl to provision and wire resources reproducibly across many.

​

Next steps