> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stateset.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Build Operations with Rust Engines & MCP

> Choose the embedded commerce engine, durable workflow engine, and MCP tools for the business operation you want to build.

StateSet's Rust engines give your application and AI agents two complementary capabilities:
**operate commerce records** and **coordinate work across systems over time**. MCP exposes
selected operations as tools your assistant can discover and call.

You do not need to write Rust to start. Use the embedded engine through a supported language
binding, configure hosted workflows in Response, or connect an assistant to the appropriate
MCP server.

## Choose the engine for the job

| System                                | What it does                                                                          | Where it runs                                                                                     | Start here                                                     |
| ------------------------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| iCommerce embedded engine             | Orders, stock, payments, returns, procurement, production, and other commerce records | In your application's process, with the selected database backend                                 | [Local order and stock example](/guides/first-operation)       |
| Temporal workflow engine / Workstream | Coordinates provider calls, model generation, review, dispatch, and durable execution | A deployed API/control plane and workers backed by Temporal; control-plane records use PostgreSQL | [Helpdesk workflow trial](/guides/first-workflow-trial)        |
| ResponseCX                            | Builds and tests support agents, knowledge, rules, and customer-facing experiences    | The Response application and its services                                                         | [First support agent](/guides/first-support-agent)             |
| MCP servers                           | Expose the permitted operations of these systems to an external assistant             | Local process or remote HTTP endpoint, depending on the server                                    | [MCP management walkthrough](/guides/manage-platform-with-mcp) |

ResponseCX and Workstream are different management surfaces. An agent created in Response is
not automatically an active-horizon workflow agent, and a local commerce database is not
automatically connected to your hosted brand.

## What you can build with the commerce engine

The linked examples execute against **`@stateset/embedded` 1.35.1**, the Node binding to the
native engine. Their results establish the behavior described here; other bindings and
versions may expose different methods.

| Operation                                                      | What the example verifies                                                         | What you integrate separately                                        |
| -------------------------------------------------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| [Create an order](/guides/orders-quickstart)                   | Stock-aware creation, reservation, insufficient-stock rejection, and cancellation | Storefront/channel synchronization and payment processing            |
| [Manage inventory](/guides/inventory-quickstart)               | Stock quantities, adjustments, and reservations                                   | Warehouse scans, location processes, and external stock ownership    |
| [Record payment and refund state](/guides/payments-quickstart) | Replay identity and balance guards                                                | The actual payment provider and settlement outcome                   |
| [Process a return](/guides/returns-quickstart)                 | Return lifecycle and completion requirements                                      | Carrier labels, physical inspection, disposition, and refunds        |
| [Approve a purchase order](/guides/supplier-quickstart)        | Supplier identity and approval transitions                                        | Supplier delivery, acknowledgements, and receiving                   |
| [Receive an inbound shipment](/guides/warehouse-quickstart)    | Partial receipt and quantity/cancellation guards                                  | Stock posting and put-away                                           |
| [Track a shipment](/guides/commerce/fulfillment)               | Tracking and shipment-state records                                               | Carrier custody, order fulfillment, and inventory consumption        |
| [Record production](/guides/manufacturing-quickstart)          | BOM definition and cumulative batch progress                                      | Material consumption, finished-goods posting, and quality evidence   |
| [Resolve a warranty claim](/guides/warranties-quickstart)      | Claim approval, completion, and denial                                            | Replacement orders, repair work, refunds, and customer communication |

A completed record is evidence about that record. For example, receiving goods does not make
inventory sellable unless the stock-posting process also completed. Preserve related IDs and
verify each outcome when combining these operations.

### Your first commerce task through MCP

Run [Your First Operation](/guides/first-operation) to create a persistent local database and
its MCP configuration. Then ask your assistant to read the generated order ID and stock SKU.
The guide supplies actual identifiers, so the assistant can compare tool results with your
independent inspection program.

The iCommerce MCP server uses that database. It does not gain access to Shopify, Response, or
Workstream merely because those services also expose MCP. Configure the source of truth and
integration explicitly before using it for real operations.

For native Rust integration and other bindings, use the
[embedded engine guide](/stateset-icommerce/stateset-icommerce-embedded) and
[binding reference](/stateset-icommerce/stateset-icommerce-bindings). Check the chosen binding's
actual surface before translating a Node example into Rust or another language.

## What you can build with the workflow engine

The Rust workflow engine separates orchestration from activities that call external services.
It provides an API, a control plane for brands/configuration/connectors, and workers that
execute workflows through Temporal.

A customer-support workflow can fetch a ticket, evaluate routing and escalation rules, gather
context, generate a response, wait for configured review, and dispatch through a provider.
The source also includes workflow families for returns, warranties, subscription retention,
payment recovery, support follow-up, delivery exceptions, and connector work. Inspect each
family's contract and deployment prerequisites; they do not all share one request schema.

Start with [the workflow API walkthrough](/guides/temporal-first-durable-workflow) or the
[workflow reference](/next-temporal/workflow), then use the matching endpoint reference for
the operation you select.

<Note>
  Durable execution is not a guarantee that an external action happens exactly once.
  An activity can be retried after an uncertain response. Provider idempotency, stable request
  identities, and reconciliation still matter for messages, orders, refunds, and other effects.
</Note>

### Long-running agents

Workstream's `start_agent` tool starts an active-horizon agent backed by Temporal and an
isolated sandbox. It returns a workflow ID that can be inspected after the initiating assistant
conversation closes. `get_agent_status` reports progress, evidence, budgets, and approval needs.

Supply the required task, duration, turn/failure, sandbox, and budget bounds using the current
start schema. Do not equate a durable agent with unlimited execution or permission to take
any action. See [active-horizon agents](/next-temporal/active-horizon-agents).

### Scheduled operations

`list_scheduled_jobs` inspects a brand's schedules, and `create_scheduled_job` configures a
supported recurring workflow. A schedule is a future source of runs, so review its target,
frequency, timezone, scope, and possible customer effects before enabling it. Inspect the
actual runs and outcomes after scheduling; schedule creation alone proves no work completed.

## Use MCP to inspect, operate, and improve

| Task                             | Server and starting tools                                                 | Evidence to retain                                              |
| -------------------------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------- |
| Understand the support workspace | Response: `describe_workspace`, `describe_vocabulary`                     | Agent IDs, configuration gaps, available templates              |
| Create and test a support agent  | Response: `provision_agent`, `get_agent`, `test_agent`                    | Saved settings and observed test answers                        |
| Turn a correction into a test    | Response: `create_eval`, `run_eval`                                       | Evaluation ID and grading result, including unavailable grading |
| Launch a workflow trial          | Workstream: `run_onboarding_accelerator`, status/report reads             | Per-step results and a dry-run workflow ID                      |
| Diagnose operational friction    | Workstream: `get_brand_scorecard`, `get_improvement_breakdown`, run reads | Representative failures, skips, and escalations                 |
| Propose a config improvement     | Workstream: `propose_config_patch`, `validate_config`, evaluation tools   | Diff, current version, and evaluation evidence                  |
| Follow a durable agent           | Workstream: `get_agent_status`                                            | Workflow ID, progress, budget, and unresolved approvals         |

These are starting points, not a fixed catalogue. Credentials, scopes, profiles, and deployment
versions determine the tools your connection exposes. Use `tools/list`, inspect input schemas,
and verify results in the same tenant and data source.

## Combine the systems around one business task

For an order-status request, a possible integration is:

1. Response or a helpdesk webhook captures the question.
2. The workflow obtains the order identity and reads the authoritative commerce system.
3. A model drafts an answer using the actual order/tracking result and approved policy.
4. The configured review process approves or escalates the draft.
5. The channel integration dispatches the reply and records its outcome.

This is an integration design, not an automatically connected demo. The commerce system might
be your embedded deployment or an external store. Choose one authority for the task and map
its order IDs to the workflow and conversation. Use
[Connect Your Operation](/guides/connect-your-operation) for that mapping.

Ask your assistant to plan the operation before enabling it:

```text theme={null}
Map an order-status workflow for my workspace. Inspect the available StateSet
MCP tools and configured systems without making changes. Identify the source
of order truth, the customer channel, the workflow brand, and the review owner.
Show which steps are already supported and which require a connector or service.
Propose the smallest trial with a concrete question, record IDs, expected result,
and verification steps. Do not create records, switch routing, or send replies.
```

**Success:** a plan tied to actual tools and systems, followed by a trial whose records and
outcomes your team can verify. Expand only after that first operation works.

## Next steps

* [Operate a durable agent](/guides/first-durable-agent): launch an approved task, inspect progress, and control its execution.

* [Platform onboarding](/guides/platform-onboarding): sign up and reach your first useful answer.

* [MCP server directory](/mcp-servers): choose the connection for the task.

* [Your first week](/guides/first-week-with-stateset): review live outcomes and measure improvement.