Skip to main content
Glama

Tail Logs

logs_tail
Read-only

Returns recent runtime logs (container stdout/stderr and HTTP request logs) for a single environment's live Cloud Run service. Takes the app_id returned by apps_list and the environment_id returned by environments_list.

Optional limit caps the number of lines returned (default 100, maximum 500). Optional since / until (ISO 8601) set the time window; since defaults to the last 10 minutes, and omitting until leaves the upper bound open (no timestamp<= clause). A timestamp without an offset is read as UTC. The response echoes the resolved since / until in UTC, with server_time, the server's current time in UTC, so you know the window that was actually queried. A since more than 5 minutes after server_time is refused, because it could only return nothing: check the offset. When the environment was never deployed (base_url null in environments_list), the response carries a note saying it has no runtime, so no logs.

Optional deployment_id (from deployments_list) scopes the tail to that deployment's Cloud Run revision. Without it, the tail is service-wide and can include output from a previously live revision on the same service. The response echoes deployment_id when the result was revision-scoped.

Optional min_severity (DEBUG/INFO/NOTICE/WARNING/ERROR/ CRITICAL/ALERT/EMERGENCY, case-insensitive) is a floor, not an exact match. HTTP request logs are mostly INFO, so a floor of WARNING or above effectively narrows the result to container output plus failed requests.

Optional contains (max 200 characters) is a server-side substring match against log message text and request URLs, filtered in Cloud Logging before limit truncation, so a match outside the most recent N lines is not silently lost. Log content is whatever the app itself writes to stdout/stderr.

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": {
      "app_id": "<app_id>",
      "environment_id": "<environment_id>"
    },
    "name": "logs_tail"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of log lines to return. Default 100, maximum 500.
sinceNoISO 8601 timestamp, read as UTC without an offset. Only return lines at or after this time. Defaults to the last 10 minutes. Refused when more than 5 minutes after the server time.
untilNoISO 8601 timestamp, read as UTC without an offset. Only return lines at or before this time. Omitted: no upper bound.
app_idYesThe app uuid returned by `apps_list`.
containsNoSubstring to match in log message text or request URL (max 200 characters). Matched server-side before limit truncation.
min_severityNoSeverity floor: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, or EMERGENCY (case-insensitive).
deployment_idNoScope to one deployment's Cloud Run revision (uuid from `deployments_list`). Omitted: service-wide, which can include a previously live revision.
environment_idYesThe environment uuid returned by `environments_list`.
organization_idNoAn organisation uuid or slug. When supplied, `app_id` is resolved within that organisation and may be a slug instead of a uuid, mirroring the Meridian web app.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The description adds substantial behavior beyond the readOnly/openWorld/destructive annotations: default time window, UTC handling, rejection of future since timestamps, behavior when no runtime exists, and revision-scoped versus service-wide differences. It also explains that contains filtering happens before limit truncation, which is important operational context.

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

Conciseness5/5

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

The description is long but appropriately sized for a nine-parameter tool with no output schema. It is front-loaded with the core purpose and then organized by parameter behavior, with every sentence contributing operational detail.

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

Completeness5/5

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

Given the parameter count, lack of an output schema, and read-only annotations, the description covers the important behavioral details an agent needs: time defaults, severity semantics, substring filtering order, deployment scoping, and the no-runtime note. The only minor omission is that organization_id is not discussed in prose, but the schema documents it fully.

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

Parameters5/5

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

Although the schema already documents all parameters, the description adds real semantic nuance: since defaults to 10 minutes, since more than 5 minutes after server_time is refused, min_severity is a floor rather than exact match, and deployment_id changes the tail from service-wide to revision-scoped. It also explains that the response echoes the resolved window and server_time.

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 states a specific verb and resource: returns recent runtime logs for a single environment's live Cloud Run service. It also identifies the two log sources (container stdout/stderr and HTTP request logs) and scope, so an agent can tell exactly what the tool does.

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 clear usage context: one environment, optional deployment scoping, optional severity floor, and optional contains filtering. It does not explicitly say when not to use it or name an alternative log tool, but the conditions for choosing the optional parameters are clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources