n8n & Make

Divinci runs a hosted MCP server at mcp.divinci.app. Both n8n and Make can act as MCP clients, so connecting them is configuration, not code: point the client at one URL, give it an API key, and an AI agent in your workflow can call Divinci's tools — chat, RAG, transcripts, releases, connectors and more — with no HTTP nodes to wire by hand.

The whole integration, in three values

| | | |---|---| | Endpoint | https://mcp.divinci.app/mcp | | Transport | Streamable HTTP | | Auth header | Authorization: Bearer divinci_… |

Do not use SSE

The legacy SSE transport (/sse + /message) was retired on 2026-08-07 and now returns HTTP 410 Gone. Many MCP clients still default to SSE, or append /sse to whatever base URL you give them.

If your client offers a transport choice, pick Streamable HTTP. If it asks for a URL, give it one ending in /mcp — not /sse, and not the bare host.

1. Mint an API key

1. In the Divinci app, go to WhiteLabel → Setup → Embed → API Keys → Create.

2. Leave every permission box unchecked and the IP whitelist empty.

3. Copy the key. It is 91 characters and starts with divinci_, and it is shown once.

Use an empty-permissions key — a scoped one may be denied everything

An empty permissions array means full access within that one whitelabel. The key is already scoped to a single workspace, so "no permissions" reads as "all permissions here", and MCP resolves such a key to the default set whitelabel:rag, whitelabel:config, whitelabel:finetune, transcript:view, transcript:use — exactly what the tool checks are written against.

A key with boxes checked is a different story, and today it is a sharp edge. The checked scopes are passed to the MCP server verbatim, and only some of them are names MCP recognises:

| Checked box | Works over MCP? | |---|---| | rag:read, rag:write | Yes | | release:read, release:write | Yes | | finetune:read, finetune:write | Yes | | transcript:read, transcript:write | No — and these are the chat scopes | | whitelabel:read, whitelabel:write, analytics:read, byok:* | No |

The first three groups work because the checkbox name happens to be spelled the same as the MCP scope. The rest are not MCP scope names and do not map to one, so they contribute no access — a key scoped with only "Write Transcripts" reaches no MCP tool at all, while the same key works fine against the REST API.

How the refusal actually looks. Verified against production on 2026-08-28 from a real n8n instance, with a key scoped rag:read,release:read,transcript:read:

Permission denied: You don't have access to the "list_transcripts" tool.
Required scope: chat:read

The message is accurate and names the scope, so the failure is easy to read once you see it. Two things about it are still worth knowing:

• The scope it asks for is not one you can check a box for. list_transcripts wants chat:read; the key UI and the CLI offer transcript:read, accept it without complaint, and it buys nothing.
• The tool list is not filtered by your scopes. tools/list returns all ~200 tools whatever the key can do, so an AI agent will happily plan a step it cannot execute and only discover it at run time. In n8n, restrict the node's tool list to the ones your key's scopes cover.

And the chat scope cannot be minted at all. Verified against production on 2026-08-28: the API validates permission names (an invented one is rejected 400 bad form data), but chat:read — the scope the chat and transcript tools require — comes back 403 Permission denied. transcript:read is accepted and grants nothing over MCP. There is currently no scoped key that reaches the chat or transcript tools.

So this is not a preference: mint the key for MCP with no boxes checked. That is the only configuration that works today.

2a. n8n

n8n's MCP Client Tool node (n8n-nodes-langchain.toolmcp) is a sub-node: it attaches to an AI Agent node and hands that agent the server's tools.

1. Add an AI Agent node to your workflow.

2. Attach an MCP Client Tool sub-node to it.

3. For the connection type choose HTTP Streamable, not SSE — the SSE option points at an endpoint that returns 410.

4. Set the endpoint to https://mcp.divinci.app/mcp.

5. Create a credential with Bearer authentication and paste the divinci_… key as the token. (If your n8n version only offers header auth, add a header named Authorization with the value Bearer divinci_….)

6. Optionally restrict which tools the agent may call. The server exposes around 200; handing an agent all of them makes its tool-selection worse, not better.

Calling one tool directly (no AI agent)

The MCP Client node (@n8n/n8n-nodes-langchain.mcpClient) is a regular node rather than an agent sub-node, so it can sit anywhere in a pipeline and call a single named tool. This is the smallest thing that proves the connection works. The parameters below are a working configuration, executed against mcp.divinci.app on 2026-08-28:

{
  "serverTransport": "httpStreamable",
  "endpointUrl": "https://mcp.divinci.app/mcp",
  "authentication": "bearerAuth",
  "tool": { "__rl": true, "mode": "id", "value": "search_tools" },
  "inputMode": "json",
  "jsonInput": "{ \"query\": \"rag\" }"
}

The credential is n8n's built-in Bearer Auth type (httpBearerAuth) with the divinci_… key as the token. The node emits one item whose content is the MCP tool result:

{ "content": [ { "type": "text", "text": "Found 5 tools matching \"rag\": …" } ] }

search_tools is a good first call because it needs no scopes and no data in the workspace — if it returns and a tool you want does not, the difference is your key's scopes, not the connection.

Note

The HTTP Streamable option arrived in n8n after the original SSE-only release of this node. If your instance offers only "SSE Endpoint", it predates that support and cannot talk to Divinci — upgrade n8n rather than trying to make the SSE path work.

2b. Make

Make's MCP Client app connects a scenario or a Make AI Agent to an external MCP server.

1. Add an MCP Client module, or attach one as a tool on a Make AI Agent.

2. Create a connection. For MCP Server, choose + new MCP server — Divinci is not in Make's verified-server dropdown, so the URL is not prefilled.

3. Set URL to https://mcp.divinci.app/mcp.

4. Put the divinci_… key in API Key / Access Token.

5. Use Call a Tool / Request to invoke one tool directly — it is the fastest way to confirm the connection before wiring an agent around it.

If Make returns 410

Make's docs describe its verified servers largely in terms of SSE endpoints and do not clearly document a transport switch. If a call fails with 410 Gone, the client reached /sse: make sure the URL you saved ends in /mcp and that nothing has appended /sse to it.

3. Verify the endpoint independently

Two checks that need no client and no key, and that tell you whether a failure is yours or ours:

# Reachable, and correctly refusing an unauthenticated caller:
curl -i -X POST https://mcp.divinci.app/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
       "protocolVersion":"2025-06-18","capabilities":{},
       "clientInfo":{"name":"curl","version":"0"}}}'
# → HTTP 401 with a WWW-Authenticate: Bearer header. This is the healthy answer.

# The retired transport, so you can recognise it:
curl -o /dev/null -w '%{http_code}\n' https://mcp.divinci.app/sse
# → 410

https://mcp.divinci.app/info also answers unauthenticated, and reports the endpoint the server considers current under protocols.mcp.streamableHttpEndpoint.

What you get

Around 200 tools across 40 modules. The ones most workflows reach for:

| Area | Tools | |---|---| | Chat | chat_create, chat_send_message, chat_get_history, chat_list | | RAG | rag_search, rag_list_files, rag_upload_prepare, rag_upload_finalize, rag_get_file_status | | Connectors | connector_list, connector_sync, connector_sync_status, connector_stats | | Releases | release_list, release_get, release_publish | | Identity | whoami — the cheapest possible connection test |

The full list is in the Tool Catalog.

Tip

Call whoami first. It requires no arguments and no write scope, so it separates "my credential works" from "my tool call is wrong" in one step.

Troubleshooting

| Symptom | Cause | |---|---| | 410 Gone | The client reached /sse or /message. Use /mcp and the Streamable HTTP transport. | | 401 with WWW-Authenticate: Bearer | No key, or the header is not Authorization: Bearer divinci_…. The MCP server does not read X-API-Key — that header works on the REST API (/api/v1/*), not here. | | 401 with a key you believe is valid | The key was revoked, expired, or has an IP whitelist that excludes your client's egress. n8n Cloud and Make call from their own IPs, not yours. | | 404 MCP is not enabled for this whitelabel | You used the whitelabel-scoped URL /{whitelabelId}/mcp for a workspace with no MCP-enabled release. The root /mcp resolves the workspace from the key itself and is the right URL for an API key. | | Every tool denied, including whoami | Almost certainly a key scoped with transcript:*, whitelabel:*, analytics:read or byok:* — none of which MCP recognises as scopes. Re-mint with no boxes checked. | | One tool missing or denied | The release curates its exposed tools, or the key lacks that tool's scope. Retest with an empty-permissions key to tell the two apart. |

The other direction: let Divinci push into your workflow

Everything above is your workflow calling Divinci. For Divinci to call you — a webhook into an n8n Webhook node or a Make custom webhook — you need a delivery channel pointing at that URL and a trigger that routes events into it.

Configure both with the MCP tools you are already connected to. The REST API cannot do it: /api/v1 exposes notifications read-only (GET /notifications, GET /notifications/counts, PATCH /notifications/{id}/read), and delivery-channel and trigger CRUD live only on the JWT-authenticated /white-label/* router, which an API key cannot reach. The MCP surface has no such gap:

| Tool | | |---|---| | notification_channel_create | Point a channel at your n8n/Make webhook URL, with an HMAC secret | | notification_channel_test | Send a test delivery before wiring anything to it | | notification_channel_verify | Required for email channels | | notification_trigger_create | Route matching events into the channel | | notification_channel_logs | The last 100 delivery attempts — start here when nothing arrives |

These need notification:read / notification:write, which an empty-permissions key resolves to. (See the scope caution above — this is another reason to mint the key with no boxes checked.)

Then handle the delivery correctly on your side: verify the HMAC, respect the ±300s replay window, and treat X-Divinci-Event-ID as an idempotency key, because a slow-but-successful handler will be retried with the same event. The full receiving contract, with verification code, is in Notifications, Analytics & Metrics.

Failure notifications are new, and partial

emitStepFailed was dead code until 2026-08-28 — a workspace that had ticked "notify me on failure" received nothing. It now fires at the two terminal boundaries of RAG file ingestion.

Two limits worth knowing before you build on it: the failed event reports stepId: "chunking", so a trigger scoped to a different step (embedding, storing, indexing) will not match it; and of the eight digest steps the configuration UI offers, only file-upload and chunking emit anything at all. Scope your trigger accordingly, and test it with notification_channel_test rather than assuming.

Which endpoint, and when

| URL | Use it for | |---|---| | https://mcp.divinci.app/mcp | API keys. The workspace is resolved from the key. This is the n8n/Make path. | | https://mcp.divinci.app/{whitelabelId}/mcp | Multi-tenant OAuth clients acting for a specific workspace. Requires MCP enabled on that whitelabel, and 404s otherwise. |

Staging and dev run the same server at mcp.stage.divinci.app and mcp.dev.divinci.app — useful for testing a workflow without spending against production.