Skip to main content
Glama

Log summary

get_log_summary
Read-onlyIdempotent

Returns the latest AI-written summary of one server's logs and its five most frequent log patterns from the last hour (nginx, Apache, Laravel, Docker, PM2, systemd), with counts and when each was last seen.

Input Schema

NameRequiredDescriptionDefault
agent_idYesThe server/agent UUID to query.

Output Schema

NameRequiredDescriptionDefault
errorNoPresent only when the call failed: why, in plain English (unknown server, server from another workspace, not a Kubernetes cluster).
summaryNoLatest AI-written summary, or null when none has been generated.
top_clustersNoFive most frequent log patterns from the last hour.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "error": {
      +      "description": "Present only when the call failed: why, in plain English (unknown server, server from another workspace, not a Kubernetes cluster).",
      +      "type": "string"
      +    },
      +    "summary": {
      +      "additionalProperties": true,
      +      "description": "Latest AI-written summary, or null when none has been generated.",
      +      "properties": {
      +        "generated_at": {
      +          "description": "When it was written, ISO 8601.",
      +          "type": "string"
      +        },
      +        "health": {
      +          "description": "healthy, degraded or critical.",
      +          "type": "string"
      +        },
      +        "summary": {
      +          "description": "Plain-English summary of the last hour of logs.",
      +          "type": "string"
      +        },
      +        "top_issues": {
      +          "description": "Most important issues named in the summary.",
      +          "items": {
      +            "type": "string"
      +          },
      +          "type": "array"
      +        }
      +      },
      +      "type": [
      +        "object",
      +        "null"
      +      ]
      +    },
      +    "top_clusters": {
      +      "description": "Five most frequent log patterns from the last hour.",
      +      "items": {
      +        "additionalProperties": true,
      +        "properties": {
      +          "count": {
      +            "description": "Occurrences in the last hour.",
      +            "type": [
      +              "integer",
      +              "null"
      +            ]
      +          },
      +          "last_seen": {
      +            "description": "Last occurrence, ISO 8601.",
      +            "type": "string"
      +          },
      +          "level": {
      +            "description": "Log level.",
      +            "type": "string"
      +          },
      +          "representative_message": {
      +            "description": "Normalised example line for the pattern.",
      +            "type": "string"
      +          },
      +          "source": {
      +            "description": "Log source: nginx, apache, laravel, docker, pm2, systemd.",
      +            "type": "string"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "type": "object"
      +}
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already establish the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower and the description still adds real behavioral context: the data is AI-written, scoped to a one-hour window, limited to five patterns, and covers specific log sources (nginx, Apache, Laravel, Docker, PM2, systemd). It does not mention pagination or freshness/caching, which keeps it from a 5.

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?

It is a single dense sentence, but front-loaded with the core purpose ('Returns the latest AI-written summary of one server's logs') before the pattern-window detail. Every clause carries information, though the trailing parenthetical log-source list and count/timestamp clause make it a run-on that could have been split for readability.

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?

An output schema exists, so return formatting needn't be restated, and the description covers scope (one server), time window (last hour), and volume (five patterns). Since this is a read-only, single-parameter tool, little else is required, though a note on how fresh the AI summary is would complete it.

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

Parameters3/5

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

Schema coverage is 100% and the single agent_id parameter is fully documented as 'the server/agent UUID to query'. The description reinforces the one-server scope but adds no format, constraint, or validation detail beyond the schema, so the baseline 3 applies.

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 names a specific verb+resource ('Returns the latest AI-written summary of one server's logs') and enumerates the exact payload: five most frequent log patterns from the last hour, with counts and last-seen timestamps. This is clearly distinguishable from siblings like get_server_overview or get_incident_timeline, which cover different resources.

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 only implied: an agent can infer this is the tool for 'what is happening in a server's logs right now', and the 'last hour' window narrows the intent. However, it never states when to prefer this over get_incident_timeline or get_server_overview, nor any exclusion conditions, so routing must be inferred.

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