Skip to main content
Glama
Sign In
Cloady

Cloady

Official
by Cloady
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Search Service Traces

searchServiceTraces
Read-only

Search service traces to inspect requests by method, route, and status, returning sample durations, request counts, median, and 95th-percentile latency for a selected time range.

Instructions

Returns a sample of the requests the service handled in the range, one per trace, with their method, route, status and duration, plus the range's request count and median and 95th-percentile duration. Filter on route, method and status (2xx to 5xx, or a code). Needs tracing on for the app and an OpenTelemetry SDK in the service; traces are kept for 7 days. 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": "searchServiceTraces"
  }
}

Input Schema

NameRequiredDescriptionDefault
envNo
sortNo`recent` lists the newest traces; `slowest` adds the range's traces above its 95th percentile and lists the slowest first; `errors` adds the range's failed traces and lists them firstrecent
rangeNoHow far back to look; the answer has 30 to 96 points across it1h
filterNoFilters, each written `<field><op><value>` with op `=`, `!=`, `=~` or `!~`; `=~` and `!~` take a regular expression matched against the whole value, ignoring case. Repeat the parameter for several; every one must hold
regionNo
appSlugYes
serviceNameYes
workspaceSlugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish a read-only, non-destructive, open-world call, so the description's added value is the operational constraints: results are a sample rather than an exhaustive list, retention is capped at 7 days, and instrumentation must be present or the call yields nothing useful. Good added context beyond the structured hints, though the sample size and any pagination behavior for the returned traces remain unstated.

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?

Three sentences, front-loaded with the return shape and followed by filtering capability and prerequisites. Dense but nearly every clause carries information; the first sentence is long and could be split for faster scanning.

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?

With eight parameters, only 38% schema coverage and no output schema, the description carries a lot of weight and does describe returned data and the trace-availability preconditions. Minor gaps remain around sampling volume, any cap on the number of returned traces, and the undocumented `env` and `region` parameters.

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?

Schema coverage is only 38%, but the description compensates meaningfully: it names the filterable fields (route, method, status) that the generic `filter` pattern leaves unspecified, explains the 2xx-to-5xx or explicit-code status shorthand, and clarifies that `serviceName` is a compose service rather than an app slug. It still says nothing about `env` or `region`.

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 opens with a specific verb and resource: it returns one sampled trace per handled request with method, route, status and duration, plus request count and median/p95. That return-shape statement lets an agent distinguish it from readTrace (single trace) and from the metric siblings without opening any schema.

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?

It gives concrete prerequisites and boundaries: tracing must be enabled for the app, the service needs an OpenTelemetry SDK, and traces are retained only 7 days. It also states what can be filtered on (route, method, status). It never names an alternative tool or says when to prefer metrics/logs instead, so it falls short of explicit routing guidance.

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