arcane-cli-mcp

arcane_logs

Read-only

Collect recent Docker container or Compose project logs, filter by time and regex, and view redacted output read-only to troubleshoot issues without exposing secrets.

Instructions

Collect recent logs from a container, or from every container of a compose project. Read-only.

LOGS ARE SENSITIVE. Redaction is best-effort: it catches common token, key, password and URL-credential shapes, but cannot recognise every secret or personal data in free text. Request the smallest slice you need (a grep, a short since, a small tail), do not repeat log contents beyond what the user needs, and never copy anything credential-like you notice into other tools or replies.

Arcane can only download a container's entire log, so the server filters it for you: it keeps the lines matching since and grep, then returns the last tail of them (default 100, max 2000), oldest first, each prefixed with its timestamp. ANSI colours are stripped and secret-looking values are hidden as [REDACTED]. If the output is too large the oldest lines are dropped (see truncated); narrow with since/grep rather than raising tail.

container: name (exact, else unique substring) or id. Pass this or project, not both.
project: compose project name; returns one section per container (at most 12).
since: relative age ("30m", "2h", "1d") or an ISO-8601 timestamp.
grep: regular expression, case-insensitive unless case_sensitive=true (e.g. "error|exception|panic").
env_id: environment id or name; see arcane_environments.

Result: {ok, env_id, logs: [{container, id, matched, returned, lines}]}. matched counts every line that passed the filters, so matched > returned means older matches were cut.

Examples:

{"container": "Immich_server", "tail": 200}
{"container": "SearXNG", "since": "1h", "grep": "error|warn"}
{"project": "immich", "since": "30m", "env_id": "homelab"}

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "arcane_logs"
  }
}

Input Schema

Name	Required	Description	Default
`grep`	No
`tail`	No
`since`	No
`env_id`	No
`project`	No
`container`	No
`case_sensitive`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: explains that the upstream API can only download full logs so the server filters (since/grep then last tail), documents default 100 and max 2000, oldest-first ordering, timestamp prefixing, ANSI stripping, [REDACTED] substitution, oldest-line truncation with a `truncated` signal, and the 12-container cap for projects. The best-effort redaction caveat and sensitivity warning are exactly the kind of risk context annotations cannot carry.

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?

Front-loaded with purpose, then behavior, then a bulleted parameter list, then examples — a logical and scannable structure with no filler paragraphs. It runs long, and the three-sentence redaction/handling admonition is slightly repetitive, but nearly every line carries operational value.

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 7-parameter, zero-coverage schema with a large behavioral surface, the definition covers invocation, filtering semantics, limits, and safety. The result shape is summarized as {ok, env_id, logs:[...]} with the meaning of `matched` vs `returned`, which is useful even though an output schema exists.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden and does: it defines container (exact name or unique substring, or id), project, since (relative '30m'/'2h'/'1d' or ISO-8601), grep (regex, case-insensitive unless case_sensitive=true, with an example pattern), env_id, and tail limits. Mutual exclusivity and defaults are spelled out, which the bare schema does not convey.

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?

States a specific verb and resource ('Collect recent logs') plus the two distinct scopes (single container vs. every container of a compose project), and immediately marks it read-only. An agent can distinguish this from siblings like arcane_api_get or arcane_project_compose without opening the schema.

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?

Gives concrete selection rules: pass container or project, not both; narrow with since/grep rather than raising tail; keep the requested slice minimal. It also points to arcane_environments for env_id. It stops short of stating when to prefer a sibling tool over this one, so it is clear context rather than a full routing rule.

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

Deploy Server