Skip to main content
Glama
Sign In
Cloady

Cloady

Official
by Cloady
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Update App Tracing

updateAppTracing
Destructive

Turn OpenTelemetry tracing on or off for an app and configure auto or manual agents; Cloady applies changes by restarting only affected services.

Instructions

Turns OpenTelemetry tracing on or off for the app. manual and auto add the app variables OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_PROTOCOL, OTEL_EXPORTER_OTLP_COMPRESSION, OTEL_RESOURCE_ATTRIBUTES, OTEL_METRICS_EXPORTER and OTEL_LOGS_EXPORTER, which point an OpenTelemetry SDK at Cloady's trace store, and each service also gets OTEL_SERVICE_NAME. auto also writes CLOADY_SERVER_MONITORING, the agent for each service (web=node,worker=python), and Cloady loads that OpenTelemetry agent into the service when it starts, with no code change. agents sets the agent of each service it names, null removing it, and the other services keep the agents CLOADY_SERVER_MONITORING already lists (none unless the app is already in auto mode); without agents Cloady detects what each service runs and picks every agent itself. off deletes them all. The app is reconciled: turning it on or off restarts its running services once, and changing agents restarts only the services whose agent changed; a request that changes nothing restarts nothing. Answers 400 for a service the app doesn't have, and 502 when the variables were saved but the app couldn't be reconciled, which repeating a manual or auto request retries. Needs the developer role.

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": "updateAppTracing"
  }
}

Input Schema

NameRequiredDescriptionDefault
envNo
regionNo
appSlugYes
requestBodyNoThe JSON request body.
workspaceSlugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the concrete side effects (OTEL_* variables written per service, CLOADY_SERVER_MONITORING, agent injection at service start), the reconciliation/restart policy (full restart on on/off, selective restart on agent changes, no restart when nothing changes), the 400/502 failure modes with the retry recipe for 502, and the developer-role requirement. This is exactly the behavioral context destructiveHint=true alone cannot convey.

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?

Front-loads the purpose correctly and every clause carries real information, but it is one dense run-on paragraph with heavy nesting of conditionals, and the `agents` passage largely restates the schema's own description of that field, which is redundant.

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

Completeness4/5

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

For a destructive, multi-mode mutation with no output schema, it covers effects, restarts, errors and auth. It does not say how `env` and `region` scope the operation (e.g. whether production services restart when toggling a preview environment), which matters for a tool that restarts running services.

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

Parameters4/5

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

With only 20% schema description coverage, the description carries the burden and mostly delivers: it defines the three mode values, the per-service `agents` map including null removal and the inherit-from-CLOADY_SERVER_MONITORING rule, and the auto-detection fallback. The `env`, `region`, `workspaceSlug` and `appSlug` parameters are still undocumented anywhere, which is the main gap.

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?

Opens with a specific verb and resource: 'Turns OpenTelemetry tracing on or off for the app.' The mode enum semantics (off/manual/auto) are then spelled out, so an agent can immediately distinguish this mutation tool from the read-only sibling getAppTracing.

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

Usage Guidelines4/5

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

Explains what each mode does and when each is appropriate: `manual`/`auto` inject OTEL variables, `auto` additionally writes CLOADY_SERVER_MONITORING and loads agents, `agents` overrides per-service detection, `off` deletes everything. It stops short of explicitly naming getAppTracing as the way to inspect current state before toggling.

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