Built a Python-native MCP server that lets Claude Desktop and Claude Code CLI interact directly with n8n. Saw several posts here about people struggling to connect Claude to n8n; this should solve it cleanly.
Nine tools covering the full workflow lifecycle:
-
list_workflows, get_workflow, create_workflow, delete_workflow
-
execute_workflow
-
activate_workflow, deactivate_workflow
-
list_executions, get_execution
A TypeScript version exists in the community already. This is the Python-native alternative; no Node.js required, built on FastMCP and httpx.
GitHub: https://github.com/DerJams/n8n-mcp-server-python
Happy to answer questions or take feedback.
1 Like
The Python-native angle is a meaningful differentiator here — FastMCP + httpx keeps the dependency footprint minimal, and no Node.js requirement makes it much easier to deploy in Python-only environments.
Question: when execute_workflow is called, does the server wait for the workflow to complete and return the output data, or does it just trigger and return the execution ID? Curious how you’re handling async executions that take a while to finish.
1 Like
Great question!
execute_workflow fires and returns immediately. The POST to /workflows/{id}/run comes back with an executionId and an initial status, not the completed output. For async executions that take a while, you would poll get_execution with that ID until the status is success or error.
But because you identified a real gap, I just pushed a wait_for_execution tool that wraps this pattern. It polls every 2 seconds, handles errors from unreachable instances or invalid IDs immediately, and returns a clean timeout message if the workflow does not finish within the window (default 60 seconds):
result = await execute_workflow("abc")
execution_id = result["data"]["id"]
final = await wait_for_execution(execution_id, timeout_seconds=120)
One thing worth noting: the output data lives at result["data"]["resultData"]["runData"] keyed by node name. Also worth noting that EXECUTIONS_DATA_SAVE_ON_SUCCESS=none in your n8n environment returns an empty data field even on success, and the /run endpoint only works with manual-trigger workflows.
Manual triggers work fine for me since I plan to trigger the workflows from Claude, but if anyone wants support for webhook triggers, I could take the time to create them. Added notes on all of this to the README.
Commit e4d5df6 if you want to pull the new tool. Appreciate the question.
The wait_for_execution wrapper is exactly what’s needed - the polling pattern is the right call here. Good heads up on the EXECUTIONS_DATA_SAVE_ON_SUCCESS=none edge case, that one trips people up often.
Webhook trigger support would be a useful addition if you get to it - quite a few n8n setups use webhook-triggered workflows as the main entry point rather than manual triggers.