Skip to main content
Glama

Read slog2 logs on a QNX target

logs
Read-onlyIdempotent

Retrieve and filter QNX system log entries by buffer, process, time, severity, or message substring, returning the newest entries with timestamps, pid, thread, severity, and message.

Instructions

Read the system log (slog2info -f -s -t) and filter it: buffer (buffer or buffer-set name), process (name substring or pid), since_s (relative to the target clock), min_severity (keep this level and more severe), contains (substring). Returns the newest limit entries with timestamps, pid, thread, severity and message.

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": {
      "target": "<target>"
    },
    "name": "logs"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
bufferNoBuffer name or buffer-set name
targetYesTarget name such as 'tb' (lowercase letters, digits, '-', '_'); must be inside the server allowlist
processNoProcess name substring or numeric pid
since_sNoOnly entries from the last N seconds of target time
containsNoCase-insensitive substring of the message
min_severityNoKeep entries at this severity or more severe

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond that: the underlying slog2info invocation, that since_s is relative to the target clock, and that results are the newest 'limit' entries with timestamps, pid, thread, severity and message.

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?

Two compact sentences, front-loaded with the core action and followed by filter details and return shape. Every phrase contributes useful information without repetition.

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 seven-parameter log-reading tool with an output schema already present, the description covers the action, filters, and return content sufficiently. It does not discuss error behavior or allowlist failures, but those are handled elsewhere in the schema and annotations.

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 description coverage is high at 86%, so the schema already explains most parameters. The description reinforces the filter semantics and clarifies ordering via 'newest limit entries', but it does not add substantial meaning beyond the schema for individual parameters.

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: 'Read the system log (slog2info -f -s -t)', then names the exact filters and return fields. It distinguishes this tool from siblings such as processes or run_poll by making clear it is a filtered slog2 log reader.

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?

The description implies when to use the tool by describing log-reading and filter behavior, but it never explicitly says when to choose it over siblings like processes, get_crash, or run_poll. There are no exclusions or prerequisites, so usage is inferable but not guided.

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