dsh-n8n-plugin: Operate n8n Workflows Inside DeepSeek Harness

What Does It Do?

It is a DSH plugin for DeepSeek Harness that brings n8n workflow operations into the harness itself. It solves the problem of pasting an n8n base URL and API key into every conversation: each instance is registered once, then every tool call targets it by alias. The plugin ships a shared instance registry, 15 agent tools and a Settings page, so what you configure in the GUI is exactly what the agent sees.

Core Features

• Multi-instance registry: register each n8n instance once under Settings with an alias (prod, staging, local, …), a base URL and an API key; every tool call picks its target by alias.
• 15 alias-addressed agent tools: list instances, list and read workflows, create, update and delete them, publish or unpublish, inspect executions, wait for an execution to settle, trigger a workflow through its Webhook, list tags and credentials, and send raw API requests.
• Offline workflow validation: checks unique node ids and names, connection targets that actually exist, webhook nodes paired with their responder, and a recommended execution order, all without contacting the instance.
• Keys stay local: API keys live only in a local config file with 0600 permissions, every response masks them to the last four characters, and the Settings page never echoes a full key.
• Built for n8n's moving API: publishing uses the modern publish endpoint and falls back to the legacy activate call only on a 404; other version differences are one raw API call away.
• Deliberate split of duties: agents can list instances but can never create or edit one, because an API key must not be dictated through a conversation.

How to Use This Plugin?

After enabling it in DSH, open the n8n instances area of the Settings page and add an instance: an alias starting with a letter or digit (letters, digits, dots, underscores and dashes only, at most 64 characters), a base URL that may include a sub-path (a trailing /api/v1 is normalized away), and an API key. Then ask the agent to work by alias, for example listing workflows on one instance, reading a full workflow document, creating or updating a workflow and publishing it in the same step, inspecting per-node results of an execution, or running a workflow through its Webhook and waiting for completion. Validate a workflow offline before publishing, and adjust behavior later from the Settings page, including the announceToAgent option that puts the absolute path of the workflow guide into the prompt so the agent can read it on demand.

How to Troubleshoot This Plugin?

If publishing returns a 404, the instance does not support the modern publish endpoint and the plugin falls back to the legacy activate call automatically, so no manual step is needed. If a tool call reports that the target instance cannot be found, check the alias spelling and the default instance setting on the Settings page. If validation reports duplicate node names or missing connection targets, fix the node ids, names and connections in the workflow JSON and validate again.