# Jarroba Tools · Logs (npm · @jarroba/mcp-logs)

Lets your AI read a CI log far too big for its context. 11 tools, takes a file path.

- Trust score: 69/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-25

## Components

- npm · `@jarroba/mcp-logs`: 69/100 (this document), [markdown](https://verifymcp.io/servers/invarato-jarroba-tools-logs/jarroba-mcp-logs.md), [page](https://verifymcp.io/servers/invarato-jarroba-tools-logs/jarroba-mcp-logs)

## Channel facts

- Registry: `npm`
- Package: `@jarroba/mcp-logs`
- Version: `0.1.4`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-25.

- **Supply Chain Security**: 98/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 31 of 96 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 19/100
  - Repository check failed: the declared repository URL returned HTTP 404.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 8 days ago).
  - Security-disclosure policy not yet verified: we couldn't inspect the source repository.
- **Schema Quality & AI Usability**: 66/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2030 tokens (~184/item across 11 items; 11 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 43/100
  - Stability observed for 13 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 98/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 94% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 11 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 12 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the Jarroba Tools · Logs MCP server?

Jarroba Tools · Logs runs locally as an npm package, launched with npx -y @jarroba/mcp-logs. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add invarato-jarroba-tools-logs -- npx -y @jarroba/mcp-logs
```

### Cursor

```json
{
  "mcpServers": {
    "invarato-jarroba-tools-logs": {
      "command": "npx",
      "args": [
        "-y",
        "@jarroba/mcp-logs"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "invarato-jarroba-tools-logs": {
      "command": "npx",
      "args": [
        "-y",
        "@jarroba/mcp-logs"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add invarato-jarroba-tools-logs -- npx -y @jarroba/mcp-logs
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "invarato-jarroba-tools-logs": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@jarroba/mcp-logs"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add invarato-jarroba-tools-logs --command npx --arg -y --arg @jarroba/mcp-logs
```

### Hermes

```yaml
mcp_servers:
  invarato-jarroba-tools-logs:
    command: "npx"
    args: ["-y", "@jarroba/mcp-logs"]
```

### Netclaw

```json
{
  "McpServers": {
    "invarato-jarroba-tools-logs": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@jarroba/mcp-logs"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add invarato-jarroba-tools-logs -t stdio -c npx -a -y @jarroba/mcp-logs
```

### Other

```json
{
  "mcpServers": {
    "invarato-jarroba-tools-logs": {
      "command": "npx",
      "args": [
        "-y",
        "@jarroba/mcp-logs"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-25 (score 69, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-09-24 (score 69, +1)

No change was recorded against any check on this day. Stability & Change Management went from 37 to 40. That category is still filling its 30-day observation window: 11 days of observed history at the previous scan, 12 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-22 (score 68, +1)

No change was recorded against any check on this day. Stability & Change Management went from 30 to 33. That category is still filling its 30-day observation window: 9 days of observed history at the previous scan, 10 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-20 (score 67, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-18 (score 66, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-17 (score 65, +15)

- [security improvement] Malware scan: unverified → pass

### 2026-09-16 (score 50, −13)

- [security regression] Malware scan: pass → unverified
- [security regression] Tool safety: pass → unverified
- [security] Stability: Stability not yet verified: we do not have a sandbox capture of the MCP schema this version of the package serves yet.
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional improvement] Stability: unverified → 0.13
- [functional] First check of Schema quality: unverified
- [functional] Package version: 0.1.2 → 0.1.4

### 2026-09-13 (score 63, +15)

- [security improvement] Malware scan: unverified → pass

## MCP tools (11)

### `log_analyze` (~163 tokens)

Understand a log without reading it: detected format, number of EVENTS (a 40-line stack trace counts as one), breakdown by level, time range, the errors with their ROOT CAUSE resolved, and the most frequent patterns. Accepts a file PATH — that is how you look at a log that does not fit in your context, such as a CI log of hundreds of MB.

Input parameters:

- `format` (string): Force the format instead of detecting it
- `from` (string): Which end to read if the file is over 32 MB
- `path` (string): Path to the log file. Use this for big logs: they do not fit in a tool call.
- `text` (string): The log as text. Alternative to `path`.

### `log_reduce` (~206 tokens)

Cut a log down to a CHARACTER budget while keeping what matters: errors with their full stack trace, the window of what happened just before, and anything that appears only once or twice. Repeats are collapsed with their count ([xN]) and gaps are marked ([...N]). Use it to hand a big log to a model without spending the context on the same line repeated.

Input parameters:

- `context` (integer): Events kept before each error
- `format` (string): Force the format instead of detecting it
- `from` (string): Which end to read if the file is over 32 MB
- `fullTraces` (boolean): false collapses each stack trace to its one-line summary
- `maxChars` (integer): Character budget for the output
- `path` (string): Path to the log file. Use this for big logs: they do not fit in a tool call.
- `text` (string): The log as text. Alternative to `path`.

### `log_patterns` (~184 tokens)

Group log lines into TEMPLATES (Drain algorithm): "connected to 10.0.0.1" and "connected to 10.0.0.7" are the same message. Turns a million lines into a few hundred readable things, each with its count, worst level and time range. Also returns the RARE ones (seen once or twice), which in a production log are usually what you were looking for.

Input parameters:

- `format` (string): Force the format instead of detecting it
- `from` (string): Which end to read if the file is over 32 MB
- `limit` (integer): How many patterns to return
- `path` (string): Path to the log file. Use this for big logs: they do not fit in a tool call.
- `text` (string): The log as text. Alternative to `path`.

### `log_stacktrace` (~131 tokens)

Read an exception stack trace (Java/JVM, Python, Node, Go, .NET, Rust, Ruby or PHP) and answer the only question anyone asks it: WHERE TO LOOK. Follows the "Caused by" chain to the root cause, separates your code from the framework, and points at your first frame. Infers which package is yours from the trace itself if you do not say.

Input parameters:

- `myPrefixes` (array): Prefixes of your own code, e.g. ["com.acme.", "src/"]
- `trace` (string, required): The stack trace, pasted as-is

### `log_lint` (~169 tokens)

Check whether the log is WELL WRITTEN — not what happened in the system: secrets or personal data printed, one line flooding the file, timestamps with no time zone (which make two machines impossible to correlate), the clock going backwards, everything at the same level, no request id, payload dumps, and orphan stack traces with no error line. Every finding comes with its count and a sample; secrets are masked.

Input parameters:

- `format` (string): Force the format instead of detecting it
- `from` (string): Which end to read if the file is over 32 MB
- `path` (string): Path to the log file. Use this for big logs: they do not fit in a tool call.
- `text` (string): The log as text. Alternative to `path`.

### `log_convert` (~190 tokens)

Convert a log from one format to another through OpenTelemetry's Logs Data Model: JSON, logfmt, syslog RFC 5424, CSV, OpenTelemetry or Elastic Common Schema. Tells you UP FRONT what the conversion loses — syslog only has eight severities and a text body, so coming down to it from JSON drops fields.

Input parameters:

- `columns` (array): CSV only: which fields become columns
- `format` (string): Force the format instead of detecting it
- `from` (string): Which end to read if the file is over 32 MB
- `host` (string)
- `path` (string): Path to the log file. Use this for big logs: they do not fit in a tool call.
- `service` (string)
- `target` (string, required): Output format
- `text` (string): The log as text. Alternative to `path`.

### `log_trends` (~238 tokens)

Answer WHEN IT STARTED, which is what a log is really asked. Compares each pattern against ITSELF rather than against total volume — in a busy service everything rises at 9am and nothing has happened — and returns three different things: what SPIKED relative to its own normal and at what time; what is NEW, which did not exist before and is usually what a deploy left behind; and what STOPPED APPEARING, which raises no counter and is often the worse news.

Input parameters:

- `bucketSeconds` (integer): Width of the time bucket; by default chosen from the log's own range
- `format` (string): Force the format instead of detecting it
- `from` (string): Which end to read if the file is over 32 MB
- `limit` (integer): How many findings to return
- `minRatio` (number): How many times its own normal counts as a spike
- `path` (string): Path to the log file. Use this for big logs: they do not fit in a tool call.
- `text` (string): The log as text. Alternative to `path`.

### `log_around` (~237 tokens)

What ELSE happened around a moment in time. Given an instant — the spike log_trends returned, or the time of an alert — find the patterns that cluster there and do not appear the same way in the rest of the log. Correlation is NOT causation, and what settles it is order: what started BEFORE comes first and is a candidate explanation; what came after is usually a consequence. Background noise is filtered out even when a narrow window lands on one of its bursts.

Input parameters:

- `at` (string, required): Reference instant, in ISO 8601 (e.g. "2026-08-27T10:40:00Z")
- `format` (string): Force the format instead of detecting it
- `from` (string): Which end to read if the file is over 32 MB
- `limit` (integer)
- `path` (string): Path to the log file. Use this for big logs: they do not fit in a tool call.
- `radiusSeconds` (integer): How far to look on each side
- `text` (string): The log as text. Alternative to `path`.

### `log_rotation` (~155 tokens)

Put a folder or a list of rotated logs into TIME ORDER, split into series. Rotation numbering runs BACKWARDS against time: `app.log.3.gz` is older than `app.log.1.gz`, and plain `app.log` is the newest; alphabetically `app.log.10` sorts before `app.log.9` while in time it comes after. Use this BEFORE reading several logs of one service, or you will read them backwards. Returns the paths already ordered, ready to feed to log_analyze one by one.

Input parameters:

- `directory` (string): Folder to look in (does not recurse). Alternative to `names`.
- `names` (array): List of file names or paths, in any order

### `log_profile_check` (~107 tokens)

Validate a Jarroba Tools LOG PROFILE (the `logprofile: 1` JSON that configures the log tools: format, server time zone, own-code prefixes, rules and AI budget). Returns ALL errors at once, each with the exact field (`rules[2].pattern`) and what was expected, so you can fix them in one pass instead of one at a time. Format documented in `public/logprofile.md`.

Input parameters:

- `profile` (string, required): The profile as JSON

### `log_profile_suggest` (~183 tokens)

Propose a LOG PROFILE from a real log: infers the format, the own-code prefix (read from the stack traces, which is where it is demonstrated) and a starting set of rules covering the most frequent errors and whatever floods the file. What it does NOT propose is the server time zone: that is not in the log, and inventing it shifts the entire timeline without anyone noticing. Accepts a file path.

Input parameters:

- `format` (string): Force the format instead of detecting it
- `from` (string): Which end to read if the file is over 32 MB
- `name` (string): Name for the profile
- `path` (string): Path to the log file. Use this for big logs: they do not fit in a tool call.
- `text` (string): The log as text. Alternative to `path`.

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/invarato-jarroba-tools-logs/jarroba-mcp-logs#diagnostics

## Score history

- 2026-09-25: 69
- 2026-09-24: 69
- 2026-09-23: 68
- 2026-09-22: 68
- 2026-09-21: 67
- 2026-09-20: 67
- 2026-09-19: 66
- 2026-09-18: 66
- 2026-09-17: 65
- 2026-09-16: 50
- 2026-09-15: 63
- 2026-09-14: 63
- 2026-09-13: 63
- 2026-09-12: 48

## Common questions

### What is the Jarroba Tools · Logs MCP server?

Jarroba Tools · Logs is an MCP server listed in the public MCP registry as io.github.Invarato/jarroba-tools-logs. Lets your AI read a CI log far too big for its context. 11 tools, takes a file path. This page covers its npm package (@jarroba/mcp-logs).

### Is the Jarroba Tools · Logs MCP server safe to use?

Jarroba Tools · Logs scores 69 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 25 September 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Jarroba Tools · Logs MCP server expose?

Jarroba Tools · Logs exposes 11 tools: log_analyze, log_reduce, log_patterns, log_stacktrace, log_lint, and 6 more. Their descriptions and schemas cost roughly 1,963 tokens of context every time the server is loaded.

### Is the Jarroba Tools · Logs MCP server still maintained?

Jarroba Tools · Logs is still listed as active in the MCP registry. We last reached this channel on 25 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Jarroba Tools · Logs MCP server under?

Jarroba Tools · Logs declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/@jarroba/mcp-logs
- Socket report: https://socket.dev/npm/package/@jarroba/mcp-logs
- Changelog RSS feed: https://verifymcp.io/servers/invarato-jarroba-tools-logs/jarroba-mcp-logs.xml
- Changelog JSON feed: https://verifymcp.io/servers/invarato-jarroba-tools-logs/jarroba-mcp-logs.json
- HTML version of this page: https://verifymcp.io/servers/invarato-jarroba-tools-logs/jarroba-mcp-logs