Conversation
… and projects Co-authored-by: HenkDz <17301927+HenkDz@users.noreply.github.com>
- Split dokploy_database into dokploy_postgres and dokploy_mysql - Merge all domain tools into dokploy_application - Final tool count: 4 consolidated tools (dokploy_application, dokploy_postgres, dokploy_mysql, dokploy_project) - All 67 original API calls remain accessible through consolidated tools Co-authored-by: HenkDz <17301927+HenkDz@users.noreply.github.com>
- Document all 4 consolidated tools with action parameters - Add comprehensive examples for each tool - Include migration guide from individual tools - Add security considerations and usage notes Co-authored-by: HenkDz <17301927+HenkDz@users.noreply.github.com>
Co-authored-by: HenkDz <17301927+HenkDz@users.noreply.github.com>
…itions Refactor existing tool definitions for consolidated architecture
|
Consoidation is needed because AI assistants get confused when given large number of tools to work with ( 67 in this case) I turned them into 4. Moreover, I added project lock and tools whitelist features as well: 
The goal behind project locking is to focus on the project we are working on and for tools whitelist is to focus on the stack the current project uses, like there's no point of having MySQL tools when I only use Postgres and need its realted tools. |
|
Love the direction of this PR! Tool consolidation is exactly the right instinct - the current 1-tool-per-endpoint approach creates massive context overhead for LLMs. I've been exploring this idea taken to its logical extreme: a single universal tool that proxies all 407 Dokploy tRPC endpoints, combined with a SKILL.md file for progressive disclosure. The token math
The trick: instead of encoding API knowledge into tool schemas, we offload it to a skill file that the LLM reads on-demand. The tool itself is dead simple: {
"method": "compose.deploy",
"params": { "composeId": "abc123" }
}I built this as a standalone proxy: mcp-dokploy-fullapi-proxy Currently used in production with Claude. The README has a compatibility matrix covering 11 AI tools based on their documented MCP support. Not suggesting this replaces your PR - consolidated tools with typed schemas are clearly better for type safety and discoverability. But for users who want full API coverage today with minimal context cost, the single-tool approach is an interesting alternative. |
This pull request introduces a major refactor to the Dokploy tool system by consolidating multiple resource-specific tools (for applications, domains, MySQL, PostgreSQL, and projects) into unified, action-driven tools. Instead of exposing each resource operation as a separate tool, the new approach provides a single tool per resource type that accepts an action parameter to determine the operation. This simplifies the tool interface and makes it easier to manage and extend.
The most important changes are:
Consolidation of Tools:
dokployApplication), MySQL (dokployMysql), PostgreSQL (dokployPostgres), and projects (dokployProject). Each tool now handles multiple actions through anactionparameter, routing to the appropriate handler internally. [1] [2] [3] [4]Exports and Tool Registry Update:
consolidated/index.tsfile to export the new consolidated tools.tools/index.tsto import only the consolidated tools and expose them as the complete set of available tools, removing the previous resource-specific tool imports.These changes greatly simplify the codebase and the interface for managing Dokploy resources, making it easier for both developers and users to interact with the system.