The generative half works well — describe the automation, get nodes and connections, run it through its webhook, read the execution. The gap to plan around is activation: n8n's API treats the active field as read-only, so the workflow you just created has to be switched on in the UI. Knowing that up front is the difference between a workflow that runs and one you assume is running. The README lists the other API gaps too, which is more useful than finding them one at a time.
An MCP server over the n8n public API, covering workflows and executions. The README now points to the author's larger n8n-mcp project as the maintained successor; this one still works and is unusually honest about which parts of the n8n API do not.
- n8n_create_workflow — a new workflow with its nodes and connections, written from a description
- n8n_get_workflow, n8n_list_workflows with filtering and pagination, and n8n_delete_workflow
- n8n_update_workflow, which needs the full node list rather than a partial change
- n8n_trigger_webhook_workflow — run a workflow through its webhook URL
- n8n_get_execution and n8n_list_executions filtered by status, so you can see what a run actually did, with n8n_delete_execution to clear records
- n8n_health_check — confirm the API is reachable and the configuration is right before anything else
- The limits are documented rather than discovered the hard way: activation is read-only through the API and has to be done in the n8n UI, tags cannot be set on create or update, running executions cannot be stopped, and there is no API for users, credentials or variables
- Some n8n instances do not accept PATCH for workflow updates, and the settings field is required but undocumented — the server supplies defaults for it
Node.js 20 or higher, a reachable n8n instance in N8N_API_URL and an API key in N8N_API_KEY. LOG_LEVEL and MCP_MODE cover the rest; logs are written to a file rather than to the transport, so they do not interfere with the MCP connection. Whatever the key can do in n8n, this can do.