Skip to main content
Glama

Convert Zapier zaps to n8n

convert_zapier

Converts Zapier export files into n8n workflow JSON locally, producing a per-step report of converted steps, items to review, and manual follow-ups.

Instructions

Convert zaps from a Zapier export (Settings → Security and data → Download my Zap workflows; one JSON file holds all zaps) into n8n workflows. Runs locally; nothing is sent anywhere. Writes one .n8n.json plus a Markdown and JSON report per zap to outputDir, and returns the reports: totals, every step with its n8n node and status, suggestions for the steps to finish by hand, and the file paths. When the export holds many zaps, call list_zaps first and pass the chosen titles or ids in "zaps". For Make blueprints use convert_make instead.

Input Schema

NameRequiredDescriptionDefault
jsonNoThe full contents of the exported file, when the user pasted or attached it instead of giving a path. Give either path or json, not both.
pathNoAbsolute path of the exported file on this computer (~ is the home folder). Give either path or json, not both.
zapsNoTitles or ids of the zaps to convert, as list_zaps shows them; titles match without regard to case. Leave out to convert every zap in the export.
outputDirNoFolder to write the results to; created if missing; existing files are kept and the new ones get " (2)", " (3)"… in their name. Default: Documents/migrate-to-n8n in the home folder.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.2.0
    • changedInput schema / properties / json / description
      Previous value: -"The exported file contents, when the user pasted or attached it"New value: +"The full contents of the exported file, when the user pasted or attached it instead of giving a path. Give either path or json, not both."
    • changedInput schema / properties / outputDir / description
      Previous value: -"Folder for the results (default: Documents/migrate-to-n8n)"New value: +"Folder to write the results to; created if missing; existing files are kept and the new ones get \" (2)\", \" (3)\"… in their name. Default: Documents/migrate-to-n8n in the home folder."
    • changedInput schema / properties / path / description
      Previous value: -"Path to the exported file on this computer"New value: +"Absolute path of the exported file on this computer (~ is the home folder). Give either path or json, not both."
    • changedInput schema / properties / zaps / description
      Previous value: -"Zap titles or ids to convert (default: all)"New value: +"Titles or ids of the zaps to convert, as list_zaps shows them; titles match without regard to case. Leave out to convert every zap in the export."
  2. First observedv0.1.1

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds real context beyond the annotations: it runs locally with nothing transmitted (reinforcing openWorldHint=false), writes one <zap title>.n8n.json plus Markdown/JSON reports per zap, keeps existing files and suffixes collisions with " (2)", " (3)", and enumerates what the returned report contains. No permission/error behavior for unwritable outputDir is mentioned, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and file source, then output behavior, then the sibling/parameter routing. Every sentence is load-bearing — none restate the tool name or repeat schema text verbatim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by describing the return value (totals, per-step n8n node and status, manual-finish suggestions, file paths) and the side effects on disk, so an agent knows both what it gets back and what it leaves behind.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds value by telling the agent to call list_zaps first and pass titles/ids via "zaps" when the export is large, and by implying path/json are alternatives. It does not add syntax detail for path or outputDir beyond the schema, so it lands just above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb (convert) and both the source resource (Zapier export file) and the destination (n8n workflows), and even specifies the exact place in Zapier's UI to obtain the file. It explicitly distinguishes itself from convert_make, so an agent can separate the two conversion tools without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the concrete trigger ('Settings → Security and data → Download my Zap workflows'), routes multi-zap exports to list_zaps first, and names the alternative (convert_make) for blueprint inputs. Both when-to-use and when-to-prefer-a-sibling are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.