Skip to main content
Glama
dfridkin

clawops

by dfridkin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Tail Gateway Logs

clawops_logs_tail
Read-onlyIdempotent

Retrieve recent gateway log lines from a managed instance to investigate activity or errors and determine what has been happening on the gateway.

Instructions

Tail recent gateway logs from a clawops-managed instance.

Use when: the user wants to investigate recent activity or errors, or asks "what's been happening" on the gateway.

Do NOT use when: the user wants real-time streaming logs (those are not well-suited to tool calls; suggest the user run clawops logs -f directly in their terminal). Do NOT use for instance-level system logs: no tool runs arbitrary remote commands, so tell the user to run clawops ssh --command 'journalctl ...' themselves.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sinceMinNoLines since N minutes ago
stackNameNoWhich stack's gateway to read. Omitted = the default stack in ~/.clawops/config.json
tailLinesNoHow many of the most recent lines to return. Keep it small; output is trimmed to 8KB regardless

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.1.3
    • addedInput schema / properties / sinceMin / description
      Added value: +"Lines since N minutes ago"
    • addedInput schema / properties / stackName / description
      Added value: +"Which stack's gateway to read. Omitted = the default stack in ~/.clawops/config.json"
    • addedInput schema / properties / tailLines / description
      Added value: +"How many of the most recent lines to return. Keep it small; output is trimmed to 8KB regardless"
  2. First observedv2.1.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already mark the tool as readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds useful behavioral context by clarifying this is not real-time streaming and that output is trimmed to 8KB regardless of requested line count.

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 opening sentence states the core purpose, followed by tightly organized 'Use when' and 'Do NOT use when' sections. Every sentence is decision-relevant and there is no filler or repetition.

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?

For a read-only log tool with three optional parameters, the description provides all needed context: what resource it targets, what cases are out of scope, and how users can accomplish those out-of-scope tasks. The output trimming behavior is also disclosed, which is sufficient given the simple log-return expectation.

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 100%, so the parameters are already well documented in the schema and the tool description does not need to compensate. The description adds a small caveat about keeping tailLines small, but it does not add significant meaning beyond the structured schema.

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 uses a specific verb and resource: 'Tail recent gateway logs from a clawops-managed instance.' It clearly distinguishes this from instance-level system logs and real-time streaming, and none of the sibling tools cover log tailing, so an agent can identify its role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit 'Use when' conditions ('investigate recent activity or errors') and explicit 'Do NOT use when' conditions with concrete alternatives: suggest `clawops logs -f` for streaming and `clawops ssh --command 'journalctl ...'` for system logs. This is model behavior for routing.

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