[P1] Avoid treating workflowId as a webhook slug

The first branch in triggerWorkflow builds a webhook URL when either webhookSlug or workflowId is provided. If both N8N_WEBHOOK_BASE_URL and workflowId are set, this assigns a URL like /webhook/<id> and skips the subsequent API branch that should call /rest/workflows/:id/run. As a result, requests that only supply workflowId attempt to hit a non‑existent webhook instead of running the workflow via the n8n REST API. Restrict the webhook branch to webhookSlug so that workflowId falls through to the API path.

Useful? React with 👍 / 👎.

When triggering a workflow via the n8n REST API (viaApi: true), the request body is being sent as { payload, query }. The n8n API expects the workflow's input payload directly as the request body, and any query parameters should be sent as URL search parameters. This will cause the workflow execution to fail or not receive the correct data.

        const response = await this.apiHttp.post(targetUrl, payload, {
          params: query,
        });

The SIGTERM and SIGINT handlers call process.exit(0) directly, which will terminate the process immediately and could interrupt in-flight requests. A graceful shutdown mechanism should be implemented to allow existing requests to complete before the server exits.

const server = app.listen(port, host, () => {
  logger.info("MCP server is running", {
    host,
    port,
  });
});

process.on("unhandledRejection", (reason) => {
  logger.error("Unhandled promise rejection", {
    reason: reason instanceof Error ? reason.message : reason,
  });
});

const shutdown = (signal) => {
  logger.info(`Received ${signal}, shutting down gracefully`);
  server.close(() => {
    logger.info("All connections closed, server shutting down");
    process.exit(0);
  });
};

process.on("SIGTERM", () => shutdown("SIGTERM"));
process.on("SIGINT", () => shutdown("SIGINT"));

The version for axios is specified as 1.12.2, which appears to be a typo as this version does not exist. The integrity hash matches axios@1.7.2. This should be corrected to avoid confusion and potential issues with tooling. You can likely fix this by removing node_modules and package-lock.json, and then running npm install again to regenerate the lockfile with the correct version string.

The CORS middleware is configured to allow requests from any origin. For a production service, this is a security risk. It's a best practice to restrict this to a whitelist of known origins, which can be managed via an environment variable.

The unhandledRejection handler logs the error but allows the process to continue. After an unhandled promise rejection, the application could be in an inconsistent state. It is generally safer to exit the process and let a process manager (like systemd or Docker) restart it cleanly.