Principle:Langgenius Dify Tool Integration

Knowledge Sources	Dify
Domains	Plugin_System, Marketplace, Frontend
Last Updated	2026-02-12 00:00 GMT

Overview

Description

Tool Integration defines how the Dify frontend discovers, categorizes, and manages tool providers that are made available through the plugin system. The principle establishes a typed provider taxonomy with five distinct tool provider categories: built-in tools (shipped with the platform), custom API tools (user-defined OpenAPI integrations), workflow tools (Dify workflows exposed as tools), MCP tools (Model Context Protocol servers), and the aggregate collection of all providers. Each category has its own dedicated query hook and invalidation mechanism, enabling independent cache management per tool type.

The tool system bridges the gap between plugins (installable packages) and tools (executable capabilities). A plugin may provide one or more tool providers, and each provider may expose multiple individual tools. The integration layer provides both the React Query hooks for data fetching and the imperative service functions for CRUD operations on tool providers and their credentials.

Usage

Tool Integration is used across the Dify application wherever tools are selected, configured, or executed:

• Tool selection in workflows -- The workflow editor uses useAllBuiltInTools, useAllCustomTools, useAllWorkflowTools, and useAllMCPTools to populate tool picker panels.
• Tool provider management -- The settings interface uses useAllToolProviders to display all registered providers and their configuration status.
• Tool CRUD operations -- Imperative functions like createCustomCollection, updateCustomCollection, removeCustomCollection manage custom API tool providers. Workflow tools have their own CRUD functions (createWorkflowToolProvider, saveWorkflowToolProvider, deleteWorkflowTool).
• Credential management for tool providers -- updateBuiltInToolCredential and removeBuiltInToolCredential manage API keys for built-in tool providers.

Theoretical Basis

Tool Integration reflects several established software architecture patterns:

• Type-safe taxonomy -- The CollectionType enum (builtIn, custom, workflow, mcp) defines a closed set of provider categories. The useInvalidToolsByType hook uses this enum to look up the correct query key, applying the Strategy pattern with a type-indexed dispatch map.
• Cache segmentation -- Each tool category has its own query key namespace (['tools', 'builtIn'], ['tools', 'customTools'], etc.), enabling granular cache invalidation. Installing a new MCP tool invalidates only the MCP tools cache, not the built-in tools cache. This follows the Partition Tolerance principle in cache design.
• Dual API layers -- The codebase provides both imperative service functions (web/service/tools.ts) and declarative React Query hooks (web/service/use-tools.ts). The imperative layer is used for one-shot operations in event handlers, while the declarative layer is used for data binding in React components. This follows the Adapter pattern where the hook layer adapts the imperative API to React's declarative rendering model.
• Provider-Tool hierarchy -- The two-level hierarchy (Collection -> Tool[]) follows the Composite pattern, where a provider aggregates multiple tools under a single identity with shared credentials and metadata.

Related Pages

• Implementation:Langgenius_Dify_UseAllToolProviders