slogx

# slogx slogx streams structured logs from a running backend over a WebSocket. This skill teaches the connect-then-query workflow on top of the `slogx_*` MCP tools. ## If the MCP isn't installed If the `slogx_*` tools aren't available (the agent reports an unknown tool when you call `slogx_list`), the slogx MCP server isn't registered with the agent yet. See [`INSTALL_MCP.md`](./INSTALL_MCP.md) for per-tool registration steps (Claude Code, Codex CLI, Cursor). Offer to install it for the user. ## Connect: discover the port from the codebase Before any log query, call `slogx_list`. If nothing is connected, **find the port by grepping the codebase** rather than asking the user — the slogx SDK init call holds it. Per language: - **TS/JS** — grep `slogx.init(` → port is the `port:` value in the config object. - **Python** — grep `slogx.init(` → port is `port=<num>`. - **Go** — grep `slogx.Init(` → port is `Port: <num>` inside the `slogx.Config{...}`. - **Rust** — grep `slogx::init(` → port is the second positional argument. Then call `slogx_connect("ws://localhost:<port>")`. Only ask the user if: - no init call exists in the codebase, OR - the port is dynamic (env var, config file, CLI flag) and you can't resolve it. The MCP holds a 500-entry ring buffer **per connection** — only logs received *after* connect are visible. Older logs are gone. ## Prefer search over dump - `slogx_search "<keyword>"` — first choice. Searches messages, metadata, and stacktraces. Cheap on tokens. - `slogx_get_errors` — fast scan for ERROR-level entries when you don't have a keyword. - `slogx_get_logs` — last resort. Use a small `limit` (~10) and a `level` or `service` filter. Never call `slogx_get_logs` with a large `limit` to "see everything" — it floods context. ## Drill in only when needed Search/get returns one-line summaries with IDs. Call `slogx_get_details <id>` for the full entry (stacktrace, all metadata) — but only after narrowing to a specific log. Don't fetch details for every result. ## Common workflows **"My API is returning 500s"** 1. `slogx_list` — confirm connection, else discover port and `slogx_connect` 2. `slogx_get_errors` — scan recent errors 3. `slogx_get_details <id>` on the relevant one 4. Read stacktrace, point to `file:line` **"Why is /checkout slow?"** 1. `slogx_search "checkout"` (optionally `level: WARN`) 2. Look for latency/duration in metadata 3. `slogx_get_details` on the suspicious entry **"What's my service doing right now?"** 1. `slogx_list` — connect if needed 2. Wait for the user to reproduce, then `slogx_search` for the action they triggered ## Buffer caveat The 500-entry buffer is in-memory and per-connection. If the MCP server restarts, history is gone. If you need older logs than what's buffered, ask the user to reproduce the issue with the connection already live.