Skip to main content
Glama
Sign In
MCP Hub

MCP Hub

by airano-ir
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Coolify: Stop application

coolify_stop_application
Destructive

Stops a running Coolify application by site and UUID, with optional Docker cleanup to free resources after shutdown.

Instructions

[UNIFIED] Stop a running Coolify application.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site": "<site>",
      "uuid": "<uuid>"
    },
    "name": "coolify_stop_application"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteYes
uuidYes
docker_cleanupNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.14.0

TDQS

C2.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false and, notably, idempotentHint=false, so the safety profile is carried by structured data. The description adds nothing beyond that: it does not explain the resulting downtime, whether the container/image persists, or the effect of the docker_cleanup parameter, which is the main behavioral risk here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence with no filler, but it is terse to the point of under-specification and the leading "[UNIFIED]" token consumes space without conveying meaning to an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with three undocumented parameters and no output schema, a single sentence is insufficient. The description should at minimum explain the docker_cleanup default and what state the application is left in.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across three parameters, and the description mentions none of them. The non-obvious docker_cleanup flag (default true, potentially removing Docker resources) and the site/uuid identifiers are entirely undocumented in the description, leaving the agent no way to understand the tool's side effects from prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Stop a running Coolify application" gives a specific verb plus resource, and the resource word distinguishes it from siblings like coolify_stop_database and coolify_stop_service. The "[UNIFIED]" prefix is unexplained noise but does not obscure the action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to stop versus restart or delete an application, no preconditions (e.g., application must be running), and no mention of what happens to in-flight deployments or traffic. The agent must infer all of this.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools