MCP-Backed Workflow Generation
MCP-backed workflow generation is an agent-first ITSM pattern where an AI agent uses Model Context Protocol tools to discover available actions, triggers, schemas, credentials, and tenant-specific integration state before generating workflow logic.
Core Pattern
Instead of asking an LLM to write workflow steps from generic knowledge, the system exposes platform capabilities through self-describing MCP tools. The agent can inspect:
- Which integrations are enabled for a tenant.
- Which actions and triggers are available.
- Required fields, optional fields, enum values, and data types.
- Tenant-specific credentials, endpoints, and version differences.
The generated workflow can then be compiled or bundled against a typed SDK and executed in a sandbox. This turns workflow generation into contract-aware planning rather than best-effort text generation.
Atomicwork Example
Atomicwork publicly describes this pattern in its Claude workflow-engine post. Its agents use Claude Agent SDK, Claude Code, and MCP tools to turn natural language into visual workflows. Atomicwork says the workflow planner queries live MCP tools, generates tenant-specific TypeScript SDK bundles, and executes generated code in isolated sandboxes.
This resolves part of the prior Atomicwork MCP ambiguity: Atomicwork is using MCP internally for workflow generation and tool discovery. It still has not been confirmed to ship a public MCP server comparable to Serval’s public MCP endpoint.
Why It Matters
- Reduces hallucinated workflow steps because the planner reads real schemas before generating actions.
- Improves tenant isolation because generated bundles can be scoped to one tenant’s tools and credentials.
- Handles enterprise drift better than static connectors because MCP tool discovery can reflect changed fields, triggers, and integration versions.
- Makes “prompt to production” workflow claims more credible when paired with human checkpoints, versioning, and sandboxed execution.
Open Questions
- Whether public MCP endpoints become a distribution channel, or remain internal implementation detail.
- How generated workflows are reviewed, versioned, tested, and governed before production use.
- Whether non-technical IT operators can safely use this without accidentally creating brittle or over-permissive automations.