n8n · Langdock

n8n in Langdock. In five minutes.

Expose your workflows to Loopthink, paste one URL into Langdock, ask. No API key, no inbound port, hosted in the EU.

Free for 2 connectors, no card · Pro €19 · EU-hosted

How to connect

Three steps. The third one is asking.

  1. 1

    Connect n8n in Loopthink

    Community node @loopthink/n8n-nodes-loopthink, outbound only. No API key, no inbound port.

  2. 2

    Paste one URL into Langdock

    Add a custom connector with a name and the URL. That is the whole form.

  3. 3

    Ask

    "Which reservations were booked in April for the Berlin property?" Every answer comes from your data, every call is logged.

Show all steps
  1. 1

    n8n → Settings → Community nodes → Install → @loopthink/n8n-nodes-loopthink. It adds the loopthink Runner trigger and the loopthink node that answers.

  2. 2

    In Loopthink, create the server with n8n as the connection and describe each tool: its name, what it returns, which parameters a model may pass. Passwords, keys and internal addresses stay on your side.

  3. 3

    Under Runners, add a pull runner. Paste its four values into the loopthink Runner credential in n8n; the secret is shown once.

  4. 4

    Build the workflow: the trigger claims a call, a Data Table, Postgres or HTTP Request node reads, Send Result masks and answers. Activate it, and the runner shows online within a minute.

  5. 5

    Someone with the permission Create integrations (Editor or Admin by default) opens Integrations → Add integration → Start from scratch → Connect remote MCP.

  6. 6

    Paste your Loopthink connector URL, choose OAuth 2.0 (Dynamic Client Registration), click Create and connect.

  7. 7

    Share the integration with users, groups or the whole workspace. Each person signs in to Loopthink once; their calls carry their own name.

Steps checked against the vendor documentation on 17 September 2026: The node on npm · n8n: install community nodes · n8n MCP Server Trigger · n8n instance-level MCP server · Langdock: remote MCP servers · Langdock: MCP directory and adding a server · Langdock: workspace permissions

Walkthrough

A reservations table, asked from Langdock.

A hotel group keeps its reservations in an n8n data table: guest, property, booking date, nights, total. The team wants to ask “which reservations were booked in April?” in Langdock and get an answer, without the table ever leaving their network.

You define the tool

Its name, what it does and which parameters a model may pass. That is the contract, and it lives in Loopthink.

Your workflow answers

A three-node workflow is enough: claim the call, read the source, send the result back masked.

Outbound only

The runner calls us. Nothing has to reach your n8n from the internet, and no credential reaches us.

The runner is a node in your own n8n. It reaches out to Loopthink, claims the calls addressed to your server and hands them to the workflow you built. No inbound port, no VPN, no credentials on our side.

  1. 1

    Install the node

    In n8n, Settings → Community nodes → Install, package @loopthink/n8n-nodes-loopthink. It adds two nodes: the loopthink Runner trigger and the loopthink node that answers.

  2. 2

    Create the server in Loopthink

    Pick n8n as the connection. It asks for nothing else: passwords, API keys and the address of any internal system stay on your side.

    The new MCP server dialog with n8n selected as the connection (n8n and Loopthink, for Langdock)
  3. 3

    Describe the tool

    Name it, say what it returns, and declare the parameters a model may pass. Here that is two optional bounds, booked_at_min and booked_at_max. The descriptions matter: they are what the model reads to decide what to send.

    The tool dialog with two optional date bounds (n8n and Loopthink, for Langdock)
    Both optional, so “all reservations” is a valid question too.
  4. 4

    Add a runner and connect it

    Under Runners, add a pull runner. You get four values; paste them into the loopthink Runner credential in n8n. The secret is shown once.

    The four values the runner credential in n8n needs (n8n and Loopthink, for Langdock)
  5. 5

    Build the workflow

    Three nodes. The trigger claims a call, the Data Table node reads, and Send Result masks the rows and sends them back. Activate it, and the runner shows online within a minute.

    A three node workflow: loopthink Runner, Read reservations, Answer (n8n and Loopthink, for Langdock)
  6. 6

    Wire the filters

    The Data Table node wants its conditions decided up front, so every row exists on every call, whether or not the model filled it. Loopthink sends a ready value for each one under $json.params, under the name you gave the parameter. Pick the column, pick the comparison once, and read the value.

    Two conditions on booked_at reading $json.params.booked_at_min and $json.params.booked_at_max (n8n and Loopthink, for Langdock)
    One condition row per parameter, each reading the value under its own name.

What the model actually asked for

“Which reservations were booked in April 2026?” arrives at the workflow like this, with the person's name and role already checked on the way in. The bounds were written by the model as plain dates and normalised on the way; had it left one out, that key would hold a date so far outside the data that the comparison cannot exclude anything.

{
  "tool": "reservations_search",
  "params": {
    "booked_at_min": "2026-04-01T00:00:00.000Z",
    "booked_at_max": "2026-04-30T00:00:00.000Z"
  }
}
The same shape, other sources

A data table is only the easiest example.

A Postgres database wired into n8n

Swap the Data Table node for a Postgres node. The connection already exists in your n8n, with its own credential, and it stays there. You can let the workflow build the query from $json.params, or write the statement in Loopthink as a fixed value, a parameter the model never sees and cannot replace:

SELECT id, guest, total
FROM reservations
WHERE country = :country
ORDER BY booked_at DESC
LIMIT 50

The :country is filled from what the model passed, escaped by declared type before it leaves us, so the statement arrives ready to run. The database password is never anywhere near us.

A Postgres node whose Query field reads $json.params.statement, with the resolved SQL shown below it (n8n and Loopthink, for Langdock)
The field holds the expression; n8n shows underneath, in green, what it resolves to for this call.

An internal API, called from n8n

Same idea, one node further. Put the path in the tool as a fixed value and let an HTTP Request node in your workflow make the call:

URL: http://pms.internal:8080{{ $json.params.path }}

Authentication is the HTTP node’s own n8n credential. Loopthink says what to reach, never what to reach it with, and the host name is one that only resolves inside your network anyway.

An HTTP Request node whose URL reads $json.params.path, with the resolved address shown below it (n8n and Loopthink, for Langdock)
Same again: the expression above, the address it resolves to below.

What never leaves your network

  • Credentials. Database passwords and API keys live in n8n, on the node that uses them.
  • Addresses. An internal host name is not something we store; a tool carries a path, your runner resolves it.
  • Unmasked data. Masking rules travel with each call and are applied in your network, before anything is sent.
  • Reachability. The runner opens the connection. There is no inbound port to expose and none to secure.

Results do pass through the platform on their way back to Langdock, masked, and are deleted on delivery. That is the trade for a runner that needs no inbound connection, and it is the one thing this deployment does differently from the gateway runner.

The node on npm →Everything about n8n →

Use cases

What people actually ask Langdock about n8n.

  • Front desk

    “Which reservations were booked in April for the Berlin property?”

  • Revenue

    “Booked revenue this month versus last month, by property?”

  • Management

    “How many nights are booked for next weekend across all properties?”

Why Loopthink

n8n has MCP options of its own. Why Loopthink?

Your n8n already reaches the systems your team asks about: a data table, a Postgres behind the firewall, an internal API. n8n's own MCP options expose that to a chat with one shared bearer token, or signed in as one user.

Loopthink runs hosted and gives Langdock a URL. Every colleague signs in with their own account and sees only what you ticked.

FAQ

Before you connect.

Does every team member need their own n8n account?
No. Your n8n is the only thing that talks to your systems, and it keeps its own credentials. Your people sign in to Loopthink with their own identity, and every call to a workflow is logged under their name. n8n seats stay where they are today.
Who has to add the connector in Langdock?
One person with the right to add connectors in your Langdock workspace, once. After that every team member enables it for themselves. Nobody pastes a key, nobody edits a config file.
Where does the n8n key live?
There is none. The runner credential in n8n, four values shown once, lets your n8n pull calls from Loopthink. Database passwords and API keys stay on the n8n nodes that use them, and nothing reaches Loopthink or Langdock.
Can somebody write to n8n from the chat?
Not unless you switch it on. Write actions are a separate row in the permission matrix and are off for every role by default. If a role needs one write tool, you grant that one tool to that one role.
What does it cost?
Free for one person and two connectors, no card. Pro is €19 a month for up to five people and every connector on the site, with roles, field masking and a 30-day audit. Team is €49 for ten people and adds your own REST APIs and SQL databases, your own domain and your own identity provider. No call needed.
We already run our own MCP server for n8n. Does it still work?
Yes. Point it at Loopthink and it inherits the same login, roles, masking and audit. Nothing on the server has to change.
When colleagues join

One matrix for n8n. Roles across, tools down.

ToolFront deskRevenueManagement
Reservations search Front desk may use Reservations searchRevenue may use Reservations searchManagement may use Reservations search
Guest lookup Front desk may use Guest lookupRevenue may not use Guest lookupManagement may not use Guest lookup
Revenue by property Front desk may not use Revenue by propertyRevenue may use Revenue by propertyManagement may use Revenue by property
Availability (internal API) Front desk may use Availability (internal API)Revenue may use Availability (internal API)Management may not use Availability (internal API)
Write actions off by defaultFront desk may not use Write actionsRevenue may not use Write actionsManagement may not use Write actions

Masked for every role: guest names and emails, phone numbers, payment details in reservation rows.

You set this once. Every Langdock user in your team gets exactly this.

n8n runs on the free tier: two connectors for one person, no card. Roles, a login for every colleague and field masking start at €19 a month with Pro. See the plans

Connect another system to Langdock

All systems and clients →

n8n in Langdock, in five minutes.

One sign-in in Loopthink, one URL in Langdock, one login per colleague.

Free for 2 connectors, no card · Pro €19 · EU-hosted