n8n-MCP 노드 지식을 활용한 AI 지원 n8n 워크플로 빌더
README 링크에서 발견 · 2 days ago
Claude를 n8n-MCP에 연결하여 n8n 워크플로우를 작성하고 검증할 수 있도록 합니다.
What they did
n8n-MCP 서버를 MCP를 지원하는 AI 어시스턴트(Claude 등)에 연결하여, 모델이 추측하는 대신 n8n 노드 문서, 속성, 오퍼레이션을 조회할 수 있도록 했다. 호스팅 대시보드 또는 자체 호스팅 npx/Docker 인스턴스를 사용하여 API 키와 함께 MCP 클라이언트를 서버로 지정한 뒤, 어시스턴트에게 워크플로우 설계를 요청했다. 노드를 선택하고, 파라미터를 채우고, 각 단계를 설명하도록 했다. 아무것도 작성하기 전에 노드 검색 및 속성 조회 도구를 사용하여 정확한 파라미터 이름과 오퍼레이션 커버리지를 확인했고, 템플릿 라이브러리와 실제 예제 구성에서 가져와 실제로 작동하는 패턴에 설계를 기반했다. 프로젝트의 안전 경고에 따라 기존 워크플로우를 복사하고, AI가 작성한 버전을 개발용 n8n 인스턴스에서 테스트하고, 백업을 내보낸 뒤에야 프로모션을 고려했다. 또한 소스 필터와 함께 커뮤니티 노드 검색을 사용하여 필요한 통합이 검증되었는지 확인한 후 의존했다.
How it went
어시스턴트가 올바른 노드 유형과 대부분 정확한 파라미터를 갖춘 워크플로 초안을 생성했으며, 각 단계에 대한 읽기 쉬운 설명도 함께 제공해 n8n 문서를 뒤지며 겪는 일반적인 시행착오를 줄여주었다. 속성 커버리지가 높아 파라미터 조회는 신뢰할 수 있었고, 작업(operation) 커버리지는 부분적이어서 몇몇 액션은 n8n UI에서 수동으로 확인해야 했다. 초안이 신뢰할 만해지려면 여전히 사람의 검토와 개발 환경에서의 테스트가 필요했다.
Worth knowing
운영 커버리지는 약 3분의 2 수준이므로 일부 노드 액션은 문서화되지 않아 모델이 파라미터를 임의로 만들어낼 수 있습니다. AI 출력은 예측 불가능하므로 프로덕션 워크플로를 직접 편집하지 말고, 복사하고 백업한 뒤 개발 환경에서 먼저 테스트하세요. 호스팅 티어는 무료 사용량을 하루 100회의 도구 호출로 제한하며, 셀프 호스팅에는 API 키와 함께 Cloudflare Access 뒤에서 서비스 토큰 환경 변수가 필요합니다.
Wiring
먼저 n8n-MCP 서버를 설치하거나 연결하세요. 호스팅 대시보드에 가입해 API 키를 복사하거나, npx/Docker로 셀프 호스팅하고 MCP_MODE와 필요한 인증 환경 변수를 설정하면 됩니다. MCP 클라이언트 설정에 서버를 등록하세요(stdio의 경우 command/args, HTTP의 경우 URL과 bearer 토큰). n8n 인스턴스가 Cloudflare Access 뒤에 있다면 N8N_CF_CLIENT_ID와 일치하는 클라이언트 시크릿을 설정해 서버가 인증할 수 있게 하세요. 연결되면 어시스턴트는 node search, property lookup, template search, community-node search 도구를 이 순서로 호출합니다. 후보 노드를 찾고, 파라미터를 확인하고, 템플릿에 기반을 두고, 그다음 workflow JSON을 출력합니다. n8n API 자격 증명은 MCP 서버 자격 증명과 분리해 두고, 쓰기 작업은 프로덕션이 아닌 개발용 n8n 인스턴스를 향하도록 하세요.
Try it yourself
# n8n-MCP 설정 및 워크플로 초안
## 1) MCP 클라이언트 설정
**호스팅 대시보드 방식** (`~/.config/mcp/servers.json` 또는 클라이언트별 동등 파일):
```json
{
"mcpServers": {
"n8n-mcp": {
"url": "https://<your-n8n-mcp-host>/mcp",
"headers": { "Authorization": "Bearer ${N8N_MCP_API_KEY}" }
}
}
}
```
**npx 자체 호스팅**:
```json
{
"mcpServers": {
"n8n-mcp": {
"command": "npx",
"args": ["-y", "n8n-mcp"],
"env": {
"N8N_API_URL": "https://<dev-instance>/api/v1",
"N8N_API_KEY": "${N8N_API_KEY}",
"MCP_MODE": "stdio"
}
}
}
}
```
**Docker 자체 호스팅**:
```json
{
"mcpServers": {
"n8n-mcp": {
"command": "docker",
"args": ["run", "-i", "--rm",
"-e", "N8N_API_URL", "-e", "N8N_API_KEY", "-e", "MCP_MODE=stdio",
"ghcr.io/czlonkowski/n8n-mcp:latest"],
"env": {
"N8N_API_URL": "https://<dev-instance>/api/v1",
"N8N_API_KEY": "${N8N_API_KEY}"
}
}
}
}
```
API 키는 n8n **개발 인스턴스**에서만 발급하고, 프로덕션 키는 사용하지 않습니다.
## 2) 연결 검증
MCP 클라이언트에서 다음을 실행합니다:
- `search_nodes` → `query: "HTTP Request"`
- 결과의 노드 타입(예: `n8n-nodes-base.httpRequest`)에 대해 `get_node` 호출 → `properties` 배열 출력
확인해야 할 항목: 노드 `type`, `typeVersion`, `properties`에 `url`, `method`, `authentication`, `sendBody`, `specifyBody`, `jsonBody` 등이 존재하는지. 이 단계에서 반환된 실제 속성명만 이후 단계에서 인용합니다.
## 3) 워크플로 초안 (Webhook → 변환 → Slack)
```json
{
"name": "draft-webhook-transform-slack",
"nodes": [
{
"parameters": {
"httpMethod": "POST",
"path": "draft-inbound",
"responseMode": "onReceived",
"options": {}
},
"id": "a1",
"name": "Webhook",
"type": "n8n-nodes-base.webhook",
"typeVersion": 2,
"position": [0, 0],
"webhookId": "draft-inbound"
},
{
"parameters": {
"mode": "manual",
"assignments": {
"assignments": [
{ "id": "f1", "name": "text", "value": "={{ $json.body.message }}", "type": "string" },
{ "id": "f2", "name": "channel", "value": "={{ $json.body.channel || '#dev-alerts' }}", "type": "string" }
]
},
"options": {}
},
"id": "a2",
"name": "Transform",
"type": "n8n-nodes-base.set",
"typeVersion": 3.4,
"position": [220, 0]
},
{
"parameters": {
"resource": "message",
"operation": "post",
"select": "channel",
"channelId": { "__rl": true, "value": "={{ $json.channel }}", "mode": "name" },
"text": "={{ $json.text }}",
"otherOptions": {}
},
"id": "a3",
"name": "Slack",
"type": "n8n-nodes-base.slack",
"typeVersion": 2.2,
"position": [440, 0],
"credentials": { "slackApi": { "id": "REPLACE_ME", "name": "Slack dev" } }
}
],
"connections": {
"Webhook": { "main": [[{ "node": "Transform", "type": "main", "index": 0 }]] },
"Transform": { "main": [[{ "node": "Slack", "type": "main", "index": 0 }]] }
},
"settings": { "executionOrder": "v1" },
"active": false
}
```
## 4) 속성 출처 및 미검증 항목
| 노드 | 인용한 속성 | 상태 |
|---|---|---|
| Webhook | `httpMethod`, `path`, `responseMode`, `options` | MCP `get_node`로 확인 필요 (아래 참고) |
| Set | `mode`, `assignments.assignments[].name/value/type`, `options` | 확인 필요 |
| Slack | `resource`, `operation`, `select`, `channelId`, `text`, `otherOptions` | 확인 필요 |
**미검증/주의 항목 (반드시 MCP로 재확인)**:
- `typeVersion` 값(Webhook 2, Set 3.4, Slack 2.2)은 버전에 따라 다를 수 있음 — `get_node`의 `typeVersion`으로 확정할 것.
- Slack `channelId`의 `__rl` 리소스 로케이터 구조와 `mode: "name"` 지원 여부.
- Set 노드의 `assignments` 중첩 구조(버전 3.x에서 `assignments.assignments` 형태인지).
- Webhook `responseMode: "onReceived"`가 해당 버전에서 유효한 enum 값인지.
- Slack 자격증명 ID는 플레이스홀더이며 실제 값으로 교체 필요.
위 항목 중 MCP 응답에서 확인되지 않은 것은 **미검증**으로 표시하고, 확인 전에는 워크플로를 활성화하지 않습니다.
## 5) 테스트 계획 (개발 인스턴스)
1. **임포트**: 개발 인스턴스에 JSON 임포트, `active: false` 유지.
2. **자격증명**: Slack dev 앱 자격증명을 `REPLACE_ME`에 연결.
3. **Webhook 스모크 테스트**:
```bash
curl -X POST https://<dev>/webhook/draft-inbound \
-H 'Content-Type: application/json' \
-d '{"message":"hello","channel":"#dev-alerts"}'
```
기대: 200 응답, 실행 로그에 Webhook → Transform → Slack 순서 기록.
4. **Transform 검증**: 실행 데이터에서 `text`, `channel` 필드가 기대값인지 확인. `channel` 누락 시 기본값 `#dev-alerts` 적용 확인.
5. **Slack 전송 검증**: dev 채널에 메시지 도착 확인. 실패 시 Slack 노드의 `channelId` 리소스 로케이터 해석 오류 여부 점검.
6. **에러 경로**: `message` 필드 누락 페이로드 전송 → Slack 노드 실패 또는 빈 메시지 동작 기록.
7. **회귀 방지**: 프로덕션 워크플로는 조회만 하고 수정하지 않음. 프로덕션 인스턴스에는 임포트하지 않음.
8. **승격 전 체크**: 4)의 미검증 항목을 MCP `get_node`로 모두 확정한 뒤에만 활성화 검토.