Skip to main content
Glama
nerdit-ai

Nerdit

Official
by nerdit-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

service_logs

Read and filter a service's runtime or build logs to debug running apps, find tracebacks, or inspect build output with literal grep and bounded tail queries.

Instructions

Use when: you need the raw output a service or its build printed.

    ``source`` picks which output you get. **Pass ``source='runtime'`` when
    you are debugging a running app** — the build and the app used to share
    one stream, so a bare ``grep`` over a deployed app still matches
    BuildKit layer chatter (``404B``, ``CACHED``, ``sha256:…``) from the
    build that produced it. Lines written by an older daemon are stored as
    stdout and therefore read as ``'runtime'`` whichever program printed
    them.

    ``grep`` keeps only lines CONTAINING that text. It is a plain
    **literal substring**, never a regex.

    All three filters run server-side inside the ``tail`` bound, so ``tail``
    counts matching lines: ``grep='Traceback', source='runtime', tail=20``
    gives the last 20 app tracebacks out of a million-line log in one
    bounded query. Prefer that over pulling a large tail and searching it
    yourself.

Input Schema

NameRequiredDescriptionDefault
grepNoKeep only lines containing this literal substring (never a regex: no anchors, no character classes, nothing to escape). Truncated to its first 200 characters server-side. Omit to keep every line.
nameYesService name or job id of an existing service (app, model or database); both resolve to the same row.
tailNoMost recent matching entries to return. Default 100; clamped to [1, 1000] here and bounded again server-side. Counts lines left AFTER ``grep``/``since``/``source``, not lines scanned.
sinceNoKeep only lines at or after this ISO-8601 UTC timestamp, inclusive (``2026-08-07T10:00:00Z``). Omit for no lower bound.
sourceNoWhich stream: ``runtime`` (the container's stdout/stderr plus its crash tail), ``build`` (the image build's output), or ``all`` (the default — both, plus the daemon's own lifecycle lines). Sent only when it is not ``all``; the daemon owns the vocabulary and 422s anything else.all
since_idNoExclusive forward cursor: only entries with a larger id. Default 0 = from the start. Ignored whenever ``tail`` is sent — and this tool always sends it — so a page is always the NEWEST matching lines, not the ones after this id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does well: it explains server-side filtering, literal substring grep, source stream mixing, and the runtime/build ambiguity for older daemon lines. It does not discuss permissions or response shape, which are minor gaps for a read-only log retrieval tool.

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?

The description is front-loaded with the use condition and then explains the filters in a logical order. It is somewhat long and repeats some schema details, but most of the text earns its place by clarifying tricky log semantics.

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

Completeness3/5

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

It thoroughly covers input semantics and filtering behavior for a 6-parameter tool. However, with no output schema, it does not explain the return format or whether lines are plain strings versus objects with timestamps or ids, leaving the agent to infer response structure.

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 100%, so the baseline is 3. The description adds meaningful interpretation beyond the schema, especially for source='runtime' and the interaction between grep, source, and tail, though it does not mention the since_id behavior documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly establishes that this tool retrieves raw service or build output, with source-specific filtering. It does not explicitly differentiate itself from sibling tools such as project_logs or diagnose_service, leaving that routing to the agent.

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 a clear when-to-use condition: when the raw output a service or build printed is needed. It also advises using bounded grep/tail queries instead of pulling large tails, but it does not name alternative tools or state when not to use this one.

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