Skip to main content
Glama
Cloady

Cloady

Official
by Cloady

Read Service Log Settings

readServiceLogSettings
Read-only

Reads a service's live log settings and explains what each setting captures, including database log categories and Redis counters, so you can verify logging behavior.

Instructions

Returns the settings that decide what the service's log holds, read from the running engine (PostgreSQL's log_* settings, MySQL's error log and deadlock settings, Redis's slowlog and memory policy) or, for the service the app's address routes to, from the ingress. Also returns what they mean for each category of the log, as the service's logFormat sorts it, and, for Redis, lines built from its memory and error counters, which Redis never logs. serviceName is a compose service.

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

Input Schema

NameRequiredDescriptionDefault
envNo
regionNo
appSlugYes
serviceNameYes
workspaceSlugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

B3.4/5.0
Behavior4/5

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

The annotations already establish that this is a safe, read-only, open-world operation. The description adds meaningful behavioral context beyond that: settings come from the running engine or ingress depending on routing, and Redis results include synthetic lines built from counters that Redis does not normally log.

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?

The description is front-loaded with the return purpose and remains reasonably efficient despite being dense. The engine examples and Redis caveat earn their place, though the first sentence is overloaded with parentheticals and could be easier to scan.

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?

The description gives a useful conceptual account of what is returned, which matters because there is no output schema. However, with five parameters and no schema descriptions, it leaves several parameter semantics unaddressed and does not fully compensate for the sparse schema.

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%, so the description must carry parameter meaning. It only clarifies that serviceName is a compose service and leaves workspaceSlug, appSlug, env, and region unexplained, so most parameters gain no semantic detail beyond their names and schema types.

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?

The description clearly states the verb and resource: it returns log-related settings for a service, including engine-specific and ingress-derived settings. It distinguishes itself implicitly from readServiceLogs by focusing on settings rather than log lines, but it does not explicitly name or route away from that sibling.

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?

Usage is implied by the purpose: use this when you need to inspect what controls a service's logging rather than the logs themselves. However, there is no explicit when-to-use guidance, no exclusions, and no direct comparison to readServiceLogs or readEngineSlowLog.

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