Skip to main content
Glama
Sign In
Cloady

Cloady

Official
by Cloady
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Analyze Deploy

analyzeDeploy
Destructive

Diagnoses failed deployments by reading logs, container output, source file names, compose configs, and non-secret variables, then lists errors and suggested fixes without changing anything.

Instructions

The AI reads the failed deploy's log, the failing containers' latest output, the names of the source's files, the compose file and the app's variables (never a secret's value), looks further with the read-only API tools when it needs to, and lists what went wrong. A problem's changes would fix it: a variable that isn't secret set to a value, a variable renamed (its value moves with it, secret or not), or new scale factors. Nothing is changed: apply them with createVar, updateVar and updateApp, then deploy again. Counts against the caller's 60 AI answers an hour.

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": {
      "workspaceSlug": "<workspaceSlug>",
      "appSlug": "<appSlug>",
      "deployId": "<deployId>"
    },
    "name": "analyzeDeploy"
  }
}

Input Schema

NameRequiredDescriptionDefault
envNo
regionNo
appSlugYes
deployIdYes
workspaceSlugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A3.5/5.0
Behavior1/5

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

The description discloses useful behavioral detail (which artifacts are read, that secret values are never exposed, and that quota is consumed), but it flatly asserts "Nothing is changed" while the annotations declare destructiveHint=true. An agent reading both signals cannot tell whether calling this is a safe read-plus-analysis operation or a destructive one, so the trust-building content is undermined by the conflict.

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

Conciseness4/5

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

It is dense and front-loaded, leading with what gets read before the outcome and the follow-up actions. The opening sentence is a long clause chain that could be split, but every clause (secret redaction, read-only lookups, quota) adds information rather than repeating the name or title.

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

Completeness3/5

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

For a complex, open-world diagnostic tool with no output schema, the description does well on behavior and on describing the shape of a proposed fix. However, it leaves all five input parameters undocumented (including the env enum) and never resolves the mutation-versus-read tension, so an agent still lacks pieces needed to call it confidently.

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

Parameters2/5

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

Schema description coverage is 0% for five parameters, so the description must carry the burden. It only indirectly implies deployId ("the failed deploy's log") and says nothing about workspaceSlug, appSlug, and especially env or region, leaving the agent to guess at required and optional identifiers.

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

Purpose5/5

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

The description names a specific verb and resource (reads a failed deploy's log, container output, source file names, compose file, app variables) and the output (a list of what went wrong plus proposed `changes`). This is clearly distinguishable from the plumbing siblings such as readServiceLogs, queryAppLogs and streamDeployLogs because the tool performs diagnosis and proposes fixes rather than dumping raw data.

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

Usage Guidelines5/5

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

It states the use case (explaining a failed deploy), the escalation path ("looks further with the read-only API tools when it needs to"), and the explicit follow-up path: apply the proposed changes with createVar, updateVar and updateApp, then deploy again. It also gives the throttling condition of 60 AI answers an hour, so the agent knows the cost of invoking it.

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