@cxtms/cx-schema 1.9.244 → 1.9.245

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@cxtms/cx-schema",
3
- "version": "1.9.244",
3
+ "version": "1.9.245",
4
4
  "description": "Schema validation package for CXTMS YAML modules",
5
5
  "main": "dist/index.js",
6
6
  "types": "dist/index.d.ts",
@@ -45,6 +45,7 @@ npx cxtms create workflow <name> --template <template>
45
45
  | `api-tracking` | Fetch tracking from carrier API |
46
46
  | `webhook` | HTTP endpoint for external callers |
47
47
  | `public-api` | REST API endpoint with OpenAPI docs |
48
+ | `mcp-tool` | Synchronous tool exposed through the organization MCP server |
48
49
 
49
50
  ### Step 2: Read the generated file
50
51
 
@@ -70,6 +71,8 @@ npx cxtms create workflow <name> --template <template>
70
71
 
71
72
  **`public-api`** — requires a top-level `api` section defining the REST endpoint. Set `api.path` with route params (e.g., `/orders/{orderId}`), `api.method` (GET/POST/PUT/PATCH/DELETE), `api.authentication` (`none`, `bearer`, `apiKey`), `api.document` (swagger doc name, default `"public"`), and `api.category` (swagger tag). Configure `api.rateLimit` with `perSecond`/`perMinute`. Each input uses `props.in` (`path`, `query`, `header`, `body`) to specify where the parameter comes from, and `props.format` for OpenAPI type hints (e.g., `uuid`, `date-time`). Body inputs may define `props.schema` with recursive OpenAPI schema fields (`type`, `properties`, `required`, `items`, `format`, `description`, `enum`); body inputs without a schema render as an object request body. Prefer `api.responses` for response documentation. Legacy `response` outputs can still use `props.type`, `props.description`, and recursive `props.schema` to describe the single `200` response. Must use `executionMode: Sync`. Control HTTP response via `response` and `statusCode` outputs.
72
73
 
74
+ **`mcp-tool`** — scaffolds a synchronous `McpTool` workflow. MCP resources use `workflowType: McpResource` and require `mcp.uri`. The resource URI must be absolute and spell out its scheme (for example, `tms://docs/shipping-terms`); relative and filesystem-style paths are invalid on every operating system. MCP tools and prompts use `mcp.name`, which must match `^[a-zA-Z0-9_-]{1,64}$`.
75
+
73
76
  **All templates** include workflow-level `events` (`onWorkflowStarted`, `onWorkflowCompleted`, `onWorkflowFailed`) and activity-level `events` (`onActivityStarted`, `onActivityCompleted`, `onActivityFailed`) with Log steps. Replace/extend these with notification tasks (Email/Send, HttpRequest, Workflow/Execute) as needed. (`onWorkflowExecuted` is a deprecated alias for `onWorkflowCompleted` — use `onWorkflowCompleted` in new workflows.)
74
77
 
75
78
  **Flow workflows** — scaffold with `basic` then set `workflowType: Flow`, remove `activities`/`triggers`, add `entity`, `states`, `transitions`, `aggregations`. Load Flow reference: `!cat skills/cxtms-workflow-builder/ref-flow.md`
@@ -100,7 +103,7 @@ workflow:
100
103
  isActive: true
101
104
  enableAudit: true
102
105
  filePath: "workflows/<name>.yaml"
103
- workflowType: Document | Quote | Flow | Webhook | PublicApi # omit for standard process workflows
106
+ workflowType: Document | Quote | Flow | Webhook | PublicApi | McpTool | McpResource | McpPrompt # omit for standard process workflows
104
107
  runAs: "system" # Optional elevated permissions
105
108
  tags: ["tag1", "tag2"]
106
109
  concurrency: # Optional