Must have feature for n8n to compete in market

### Summary

Currently, connecting service nodes (e.g., Gmail, Slack, Notion, GitHub) as tools to an AI Agent requires adding separate tool nodes for every individual operation (one node to Read, one to Send, one to Draft). This causes canvas bloat, redundant credential links, and rigid workflows.

We propose adding a “Dynamic / Multi-Action” mode for AI Tool nodes so an AI Agent can receive the entire integration’s toolset in a single connected node, similar to MCP (Model Context Protocol), Composio, and Hermes.

### The Problem

* Canvas Clutter: An agent handling email needs 4+ separate Gmail tool nodes wired into the agent.

* Maintenance Overhead: Any credential or permission update requires modifying multiple canvas blocks.

* LLM Inefficiency: Modern LLMs excel at dynamic tool calling; forcing single-purpose nodes creates unnecessary canvas overhead.

### Proposed Solution

1. Dynamic Tool Mode on Node-as-a-Tool:

* In the tool node config, allow selecting:

 - Single Operation (current static mode)

 - Dynamic Multi-Operation (exposes the node's full resource API schema)

2. Dynamic Schema Injection:

* The node exposes operations under a single unified schema:

 json

 {

   "action": "search | read | send | draft",

   "parameters": { ... }

 }

 3\. Runtime Routing:

* The AI Agent receives 1 tool and dynamically selects the operation and arguments based on the prompt instructions.

### Reference

Tracked discussion on GitHub: Dynamic Multi-Action AI Tool Nodes (Unified Tool Definition for AI Agents) · Issue #39932 · n8n-io/n8n · GitHub

إعجاب واحد (1)

Two existing routes already get most of what you describe. The MCP Client Tool exposes a whole MCP server’s toolset to an AI Agent through one connected node, and the agent picks the operation and arguments from the advertised names and schemas - that is essentially your action/parameters shape. For services that are not behind an MCP server, wrap a small sub-workflow as a Custom n8n Workflow Tool that takes an action plus a parameters object and switches internally, so one canvas node still fans out to read/send/draft. One thing worth weighing before the dynamic mode lands: tool-selection accuracy falls as the number of candidate tools grows, so a single node exposing twenty operations is not automatically better than four focused ones - the MCP pattern works largely because every operation carries its own clean name and JSON schema.