Activity

Two related gaps in the application tool that I hit while bringing up a NestJS+Vite monorepo on Coolify.

What I observed

1. dockerfile_location is not in the zod schema at all

In src/lib/mcp-server.ts the application tool's schema (around lines 458–495) declares health check fields, basic create fields, and update fields — but it does not declare dockerfile_location (nor dockerfile_target_build, base_directory, publish_directory, install_command, build_command, start_command, watch_paths). All of these are present on Application (get response) and on the UpdateApplicationRequest type in src/types/coolify.ts (line 365), so they're known to be valid on Coolify's API.

Effect: passing dockerfile_location to update is silently stripped by zod before the spread, so the field never reaches Coolify. There is no way to set the Dockerfile path for a monorepo via MCP today; the workaround is curl PATCH … with the same field.

2. Health check fields are accepted on update but ignored on every create_*

The update case (mcp-server.ts ~line 648) spreads all schema-validated args into updateApplication, which is why issue #62's request worked — for update. But the four create_* cases (create_public, create_github, create_key, create_dockerimage) hand-pick fields one by one, and none of them includes any health_check_* field, even though those fields are declared in the same tool's schema.

Effect: create_key/create_github/etc. with health_check_enabled: true, health_check_path: '/health', … returns {uuid, domains} and a get_application immediately afterwards shows health_check_enabled: false and the default path. To get healthchecks set, the only path is to follow the create with a update round-trip (or curl PATCH).

The same hand-picking ignores any of the build-config fields listed in §1, even though CreateApplicationPublicRequest (types/coolify.ts:250) includes base_directory, publish_directory, install_command, build_command, start_command — they're typed but never passed in.

Repro

Coolify v4 / coolify-mcp 2.x. From a real session today:

// MCP create_key with everything I needed
{
  "action": "create_key",
  "name": "i-access-api",
  "project_uuid": "...",
  "server_uuid": "...",
  "destination_uuid": "...",
  "git_repository": "[email protected]:org/i-access.git",
  "git_branch": "main",
  "private_key_uuid": "...",
  "build_pack": "dockerfile",
  "ports_exposes": "3000",
  "domains": "https://i-access-api.example.com",
  "instant_deploy": false,
  "health_check_enabled": true,        // schema-valid, dropped on create
  "health_check_path": "/health",      // schema-valid, dropped on create
  "health_check_port": 3000,           // schema-valid, dropped on create
  "health_check_start_period": 60      // schema-valid, dropped on create
  // dockerfile_location: "/apps/api/Dockerfile" — would be schema-rejected
}

get_application afterwards: dockerfile_location: null, health_check_enabled: false, health_check_path: "/". The same fields applied via raw PATCH /api/v1/applications/{uuid} work end-to-end (I confirmed against this Coolify instance).

Suggested fix

Two small, independent changes; happy to open a PR if either looks good:

1. Extend the zod schema in the application tool with the missing build-config fields: dockerfile_location, dockerfile_target_build, base_directory, publish_directory, install_command, build_command, start_command, watch_paths. They already exist on UpdateApplicationRequest, so this fixes update by itself.

2. In the four create_* handlers, forward the health check fields and the build-config fields from §1 into the createApplication* calls. The Create…Request interfaces in src/types/coolify.ts need the same fields added (they're already on the equivalent update type).

I'd keep the existing hand-pick pattern rather than switching create_* to a spread, so the schema stays authoritative and fields surface in tool docs.

Storage / persistent volumes are out of scope here — covered by #172 which is already open.

Reproduced on a live Coolify v4 instance behind coolify.example.com; the underlying API accepts every one of these fields on PATCH today.