examples

# Provisioning Examples Scenario walkthroughs demonstrating the full provisioning lifecycle: discovery, analysis, import, credential setup, and activation. All tool references use `~~placeholder` syntax — see CONNECTORS.md for provider fallback. ## Available Scenarios | Scenario | Description | Reference | |----------|-------------|-----------| | Provision a new instance | Set up a fresh n8n instance with 10 foundational workflows | `references/scenarios/provision-new-instance.md` | | Find and import community workflow | Search official + community sources, fetch JSON, import | `references/scenarios/find-and-import-community-workflow.md` | | Automation suite deployment | Deploy a coordinated "Slack + GitHub DevOps" suite of 5 workflows | `references/scenarios/automation-suite-deployment.md` | ## Quick Start: Simplest Provisioning Flow The minimum viable path from search to deployed workflow: ### Step 1: Search for a template ``` ~~template_search("slack notification new github issue") ``` Review results. Pick the best match by quality signals: - `totalViews` / `views > 10,000` — well-established - Short node list (< 15 nodes) — simpler to configure - Recent `createdAt` — likelier to use current nodes - Free (no `purchaseUrl`, and `price` 0 or absent) — a paid template needs the user's go-ahead; for a bare ID look the price up in the search first If the n8n-mcp search finds nothing, the same search runs against `api.n8n.io` (`template-discovery` skill). ### Step 2: Analyze the template ``` ~~template_get(templateId={template_id}, mode="full") ``` n8n-mcp reads a local database of about 2,350 templates. On `Template <id> not found`, fetch the template from `api.n8n.io` (`curl -s https://api.n8n.io/api/workflows/templates/{template_id}`, workflow JSON in `.workflow`). Check: - **Node types** — are all nodes available on the instance? - **Credentials needed** — what API keys / OAuth tokens are required? - **Complexity** — how many nodes, how many connections? ### Step 3: Deploy ``` ~~template_deploy(templateId={template_id}) ``` The deploy tool handles: - Auto-fix for expression format and `typeVersion` issues - Credential stripping (credentials are not imported — must be configured manually) - Workflow is created as an **unpublished draft** A template that only exists on `api.n8n.io` is imported with `~~workflow_create` instead (`name`, `nodes`, `connections`, `settings`; see `single-workflow-import`, Path 1b). ### Step 4: Verify ``` ~~workflow_list ``` Confirm the workflow appears in the list. Check its status (should be unpublished). ### Step 5: Configure and publish 1. Open the workflow in n8n UI 2. Set up required credentials for each node 3. Test with a manual execution 4. Publish the workflow (n8n 2.x calls this step Publish; "activate" is the old name) — only when the user asks --- ## Common Patterns Across Scenarios ### Pre-flight checks Every provisioning session should start with: ``` 1. ~~instance_health → is the instance reachable and the API key accepted? 2. ~~workflow_list → what's already deployed? 3. ~~credential_manage → what credentials exist? ``` This prevents conflicts and identifies reusable credentials. ### Search escalation When the official library doesn't have what you need: ``` 1. ~~template_search → official library (12,900+ templates: n8n-mcp local database first, then api.n8n.io) 2. Community GitHub repos → Zie619, enescingoz, etc. (see community-source-discovery skill) 3. Community platforms → n8nworkflows.xyz, n8nfind.net, etc. 4. Build from scratch → use n8n-native-mcp SDK tools ``` ### Credential planning Before deploying multiple workflows: 1. List all credential types needed across all workflows 2. Group by provider (e.g., all Slack workflows share one OAuth token) 3. Set up credentials once 4. Map to all workflows that need them ### Post-deployment verification After every deployment: 1. Confirm workflow exists in `~~workflow_list` 2. Check workflow is an unpublished draft (nothing is auto-published) 3. Configure credentials 4. Run a manual test execution 5. Check execution output for errors 6. Publish only after successful test and on the user's request ## Convention Notes - All examples use the CONNECTORS pattern — `~~placeholder` for tool-agnostic instructions - Workflows are always imported as unpublished drafts — never auto-publish (n8n 2.x: publish replaces activate) - Credentials are always stripped during import — must be configured manually - Batch deployments use tags for grouping: `suite-{name}-{date}`, added after each deploy with the `addTag` operation (the deploy tools take no tags) - Community JSON is always validated before import