Automation capability discovery

Authenticated GET /v1/orgs/:orgId/automations returns the existing workflows array and an additive capabilities object. Existing consumers may ignore it. The registered automation_list MCP tool forwards this exact response through its existing internal HTTP path, inside { dataTrust: "untrusted", data: ... }. Workflow names, action text and results remain untrusted input.

capabilities.catalog contains:

• formatVersion: 1, an advisory identity (sha256:…), and sourceIdentity. Identity covers the canonical schema/engine source, serialized input schemas, limits and published semantics. The catalog is capped at 40,000 serialized bytes. It changes with supported inputs or semantics; it is neither a workflow version nor an execution grant/admission signature.
• Exact canonical triggers, actions, and input JSON Schemas for creation, update, action and condition. These come directly from the existing Zod schemas. Unsupported conversions throw; they never become permissive wildcard schemas.
• limits: current authored actions/conditions, workflows, recursion depth, record/workflow and org hourly admission, wait count and total wait duration. Scalar, string, array and individual parameter bounds are in the input schemas.
• semantics: additional canonical refinements, tenant reference prerequisites, dry-run/effect behavior, cancellation, authority and error recovery.

JSON Schema is structural validation, not the entire server validator: wait durations are additive, positive and cumulatively bounded; a wait cannot be last or combined with lifecycle expansion. field/tag conditions require a key; in requires an array. Draft merge tokens must use the published merge fields, optionally with a fallback of at most 80 characters. Canonical API validation remains decisive. There are no new executor, tools, agentic/video/remote actions or public cron nodes. Lifecycle expansion requires an actual lifecycle event/instance and is bounded by the existing engine's expanded-action limit; missing context is an unsupported prerequisite, never manufactured success.

availability.automations: true means the caller reached the existing enabled surface. It does not enable optional action dependencies. For example, webhook_out still requires CRM webhooks, an existing matching CRM event and a registered, enabled tenant endpoint. No endpoint URLs, secrets, members, tokens or private reference values appear in the catalog.

authority is deliberately separate from the catalog. canRead: true records successful admission to this list request. crmEditPermission and credentialAllowsWrites describe the current read context. canWrite: false means one of those checks already denies writing. Otherwise canWrite: null and writeAdmission: "requires_effect_time_authorization" explicitly withhold any promise of admission for a future write. Current membership/key grants, creator ceiling, org policy, per-action permissions, references and normal approval remain authoritative when writing/executing. Discovery consumes no grants and does not cache authority for later calls.

Feature-off and foreign-tenant routes retain their existing 404 behavior; anonymous callers do not get a catalog. MCP registration still requires its existing CRM/API/automation flags and credentials. This change does not broaden transport admission: in particular it does not make a read-only key eligible for MCP POST transport where the existing auth rules deny it. Such a key can still discover via its existing allowed HTTP GET.

dryRun records planned run/step history without action effects or durable waits. draft_email writes a planned outbound timeline email for human review; it never sends mail and honors suppression/do-not-contact. Waits resume through the existing internal worker after current-state and author checks; replies (with cancellation enabled), stops, edits, switches and failed rechecks cancel them; loss of author permission fails a resumed segment without applying effects. A webhook action's queued step is not proof of delivery: use the existing delivery log for transport confirmation. Read/transport errors remain unknown.

On invalid fields/unsupported actions, use the returned schema and prerequisites and preserve the server error. On expectedVersion conflict, reread and reconcile. After ambiguous write transport failure, read persisted state before retrying. Catalog identity is advisory and never bypasses any of these checks.

Conversion follows Zod's JSON Schema API, using input mode and the default refusal for unrepresentable forms. Parent integration owns regeneration of combined central OpenAPI/docs outputs and normal release.