guck.searchLABSCO SUMMARY
The output cap is the design, not a limitation.
Refusing to return a payload that would blow past the character limit — and returning the message-length statistics instead so you know how to narrow — is the opposite of how most log tools behave, and it is right for this consumer. So is the documented order: stats first with a tight window, then search, and tail only if live streaming is genuinely needed. Redaction runs on both write and read against configured key names and regexes, which matters when the thing reading your logs is a model. Session and trace ids are kept separate on purpose, since startup, cron and background events belong to a run but to no request.
What it is
A small JSONL telemetry store with an MCP interface. Any runtime can emit events into it — through the SDKs, or by wrapping a command's stdout and stderr — and the MCP tools are deliberately query-shaped rather than tail-shaped, because the failure mode being designed against is a model drowning in logs.
What you get
guck.stats— the narrow-window overview you start with, before looking at any individual eventguck.search— boolean search over the message withAND,OR,NOT, parentheses and quoted phrases, pluscontainsfor substring matching across message, type, session and dataguck.search_batch— several named searches in one request, each with its own filters and limitsguck.sessionsfor run-scope correlation, andguck.tailwhich exists but is deliberately not the documented default- Output shaping that keeps responses small:
fieldsto project only the columns you need including dotted paths,flattento lift them to top level,templatefor one formatted line per event, andmax_message_charsto trim long messages - A hard output cap — responses over
mcp.max_output_charsreturn a warning with average and maximum message lengths instead of the payload, unlessforceis set - Capture without code changes through
guck wrap, plus JS, browser and Python SDKs and a Vite dev plugin guck checkpoint, which writes a timestamp that later queries use as their default time window
Requirements
No account and no key — everything is local. Install the CLI with npm install -g @guckdev/cli or pnpm add -g @guckdev/cli, then register guck mcp as the server command. Configuration comes from a .guck.json at the repo root, with .guck.local.json merged over it for per-developer overrides; GUCK_CONFIG_PATH points at a specific file, and each MCP tool also accepts a config_path for multi-repo use. GUCK_DIR overrides the store root, which defaults to ~/.guck/logs — pointing several services at one absolute directory is how you get cross-service tracing. GUCK_SESSION_ID correlates a run. Python and browser SDKs are separate installs. MIT licensed.
Setup effort
One command — npm install -g @guckdev/cli
USE CASES
Starting an investigation without drowning
Scope with stats over a short window and one service, then search only the slice that looks wrong.
Asking several questions at once
Batch the searches — errors, warnings, one specific boundary — with per-search limits, in a single request.
Keeping responses small enough to read
Project only timestamp, service and message through a text template rather than returning whole events.
Tracing across local microservices
Point every service at one store directory with a shared session id and distinct service names, then query across all of them.
Comparing before and after a change
Write a checkpoint, re-run, and let the default time window anchor every query to what happened since.
5 tools
Listed in project docs. Your client may show a different list.
guck.search_batchguck.statsguck.sessionsguck.tailBEFORE YOU INSTALL
What to know first
Tools you get
5 tools named in the project's documentation.
Requires
guck on PATH
Where it runs
Both documented clients run the server on your machine.
INSTALLATION
Connect your client
Server setup
npm install -g @guckdev/cliMCP Clients
Claude, GitHub Copilot
{
"mcpServers": {
"guck": {
"command": "guck",
"args": [
"mcp"
],
"env": {
"GUCK_CONFIG_PATH": "<YOUR_GUCK_CONFIG_PATH>"
}
}
}
}