Add comprehensive tool coverage for Dokploy API

[limehawk]

Summary

This PR resolves the issue where MCP tools with large/complex schemas fail to execute properly (e.g., compose-update with 43 fields, application-update with 87 fields).

Root Cause

Claude API requires JSON Schema draft-2020-12, but the MCP SDK's default Zod-to-JSON-Schema conversion outputs draft-07, causing schema validation failures.

Fixes

• Upgrade to Zod v4 for native z.toJSONSchema() with target: "draft-2020-12" support
• Pre-convert schemas before MCP SDK registration to bypass SDK's draft-07 conversion
• Normalize response IDs to top level for consistent LLM tool chaining (e.g., data.projectId always accessible)
• Fix Zod v4 breaking changes:
  • z.record(z.string()) → z.record(z.string(), z.string())
  • ZodError.errors → ZodError.issues

Testing

Verified with 8 comprehensive scenarios against a live Dokploy sandbox:

1. ✅ Full application deployment workflow
2. ✅ Database stack setup (PostgreSQL + MySQL)
3. ✅ Docker Compose deployment with YAML
4. ✅ Complex 87-field application updates
5. ✅ Multi-environment setup (prod/staging/dev)
6. ✅ Mounts and port mappings
7. ✅ Git-based deployments
8. ✅ Error handling validation

All scenarios pass with proper cleanup (0 orphaned resources).

API Limitations Documented

Some Dokploy API endpoints don't return IDs on create:

• mounts.create, port.create, redirects.create, security.create

These operations succeed but LLMs cannot chain delete/update without querying for IDs first.

---

🤖 Generated with Claude Code

[yoinks-yoinks]

Great work! This comprehensive coverage is exactly what the community needs. Looking forward to seeing this merged!

[yoinks-yoinks]

Issue in this PR: MCP Tools with Large/Complex Schemas Fail to Execute Properly

Description:
Dokploy MCP tools that return large JSON responses or have complex parameter schemas are experiencing execution failures. This appears to be a schema validation or response size limitation issue in the MCP implementation.

Evidence:

Tools with extensive parameter schemas (like compose-update with multiple complex fields) show inconsistent behavior

Some tools work while others with similar complexity fail

Root Cause:

Potential schema validation timeout for complex parameter sets

Response size limits in MCP protocol handling

JSON parsing issues with deeply nested or large response objects

Reproduction Steps:

Call Dokploy MCP tools with complex schemas (compose-update, application management tools)

Observe inconsistent execution or timeout failures

Compare with simpler tools that work reliably

Proposed Resolution:

Implement response streaming for large JSON payloads

Add schema validation timeouts with configurable limits

Split complex tools into smaller, focused operations

Add response size monitoring and chunking

Impact: Blocks full utilization of Dokploy management capabilities through MCP

Priority: High - affects core functionality

[limehawk]

Thank you for testing @yoinks-yoinks I'll look into this and add a commit. This may be a Zod3 vs. Zod4 thing