Skip to main content
Glama
Sign In
Cloady

Cloady

Official
by Cloady
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Get App Runtimes

getAppRuntimes
Read-only

Returns what each compose service runs from build logs, image config, and start command, plus the OpenTelemetry agent to load or why none.

Instructions

Returns what each compose service runs, read from its latest build log, its image's configuration and its start command, and the OpenTelemetry agent Cloady recommends loading into it, or why none. Agents exist for Node.js 18.19 and 20.6 or later, Python 3.10 or later, Java 8 or later and .NET 8 or later. Databases, caches, queues, mail servers, proxies, TCP services and functions aren't inspected. Reads public registries, so it can take a few seconds.

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>"
    },
    "name": "getAppRuntimes"
  }
}

Input Schema

NameRequiredDescriptionDefault
envNo
regionNo
appSlugYes
workspaceSlugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover safety (readOnlyHint=true, destructiveHint=false) and openness (openWorldHint=true), so the bar is lower. The description still adds real context beyond them: it reads public registries, so latency of a few seconds is expected, and it discloses which service classes are skipped rather than silently returning nothing.

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?

Front-loaded with the return content, then exclusions, then the latency caveat; almost every clause earns its place. The runtime-version inventory (Node 18.19/20.6, Python 3.10, Java 8, .NET 8) is somewhat over-specified for a tool description but does let an agent pre-judge null results.

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?

With no output schema, the description must convey the return shape, and it does so at a high level (runtime detection plus agent recommendation or the reason none exists). It stops short of explaining the response structure or any of the four inputs, which leaves gaps for a tool with required workspace/app identifiers and an environment selector.

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 four parameters, so the description carries the full burden and fails to mention any of them. workspaceSlug, appSlug, env (the one enum) and region — including whether env defaults to production or how region affects registry lookups — are never explained.

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?

States a specific verb and resource — returns what each compose service runs — and names the evidence sources (latest build log, image configuration, start command) plus the OpenTelemetry agent recommendation. An agent can distinguish this from siblings like getAppServices or readServiceDependencies without opening a schema.

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

Usage Guidelines3/5

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

The description scopes the tool by exclusion (databases, caches, queues, mail servers, proxies, TCP services and functions aren't inspected), which implicitly tells the agent when not to bother. However, it never names an alternative sibling or states the situation that selects this tool over getAppServices or getAppTracing.

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