Answer homelab topology and cross-host correlation questions using cortex's graph-backed inventory — what services run on a host, what depends on what, fleet-wide heartbeat state, correlating events across hosts around a point in time, and graph entity/neighborhood/explanation queries. Use whenever the user asks "what's running on <host>", "what depends on <service>", "fleet health", "what else happened around this time", "correlate this across hosts", or wants an evidence-backed explanation of how two things in the homelab are connected.
Troubleshoot cortex connection failures, missing logs, unhealthy containers, restart loops, or vague "logs aren't working" reports.
This skill should be used when the user asks to "search logs", "check errors", "tail logs", "show recent logs", "find log entries", "correlate events", "list hosts", "log stats", "syslog", "check homelab logs", or mentions system logs, syslog, log analysis, or log intelligence across homelab hosts.
This skill should be used after running cortex action=abuse_investigate to analyze the resulting evidence bundle. Use when the user asks to assess frustration incidents, evaluate abuse signals, analyze agent or user friction, produce a frustration report, or follow up on abuse_investigate results.
This skill should be used after running cortex assess hooks [--hook <name>] (or the underlying hook_investigate MCP action that produces HookIncidentEvidence) to analyze why a Claude Code/Codex/Gemini hook failed, timed out, misfired, or otherwise degraded the agent session. Use when the user asks to assess hook reliability, evaluate why a PreToolUse/PostToolUse/Stop/SessionStart hook failed or blocked a flow, propose hook script or hook-config changes, or follow up on hook incident evidence.
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
This plugin requires configuration values that are prompted when the plugin is enabled. Sensitive values are stored in your system keychain.
no_authRun cortex without service-local MCP auth. Use this only when an upstream gateway or reverse proxy enforces auth before traffic reaches cortex. Server mode only.
${user_config.no_auth}data_dirDirectory holding the SQLite database file (cortex.db plus its WAL/SHM sidecars in WAL mode). Defaults to the plugin's persistent data directory ($CLAUDE_PLUGIN_DATA), which survives plugin upgrades. Override only if you need the DB on a different volume — e.g. a larger or faster disk. The directory must exist and be writable by the user running the service. Server mode only.
${user_config.data_dir}mcp_hostInterface address the MCP HTTP server binds to. 0.0.0.0 makes the MCP endpoint reachable from other hosts (required if any client-mode peer needs to connect). 127.0.0.1 keeps it local-only (use this if you front the server with a reverse proxy on the same host, or only query from this machine). Server mode only.
${user_config.mcp_host}mcp_portTCP port the MCP HTTP server listens on (serves POST /mcp and GET /health). Default 3100. Must match the port in server_url for clients to reach you. Avoid 3000 to dodge the common Node.js dev server collision. Server mode only.
${user_config.mcp_port}api_tokenBearer token for MCP HTTP authentication, sent on every request as `Authorization: Bearer <token>`. Server mode: pick any value — that becomes the secret the server enforces (generate one with `openssl rand -hex 32`, or use `just gen-token`). Client mode: paste the token your server admin configured. The same token must match on both sides; mismatched tokens return 401.
${user_config.api_token}auth_modeServer auth mode. bearer keeps the static API token only. oauth enables Google OAuth/JWT for clients like Codex while the generated API token remains accepted for this Claude Code plugin connection. OAuth mode requires public_url, google_client_id, google_client_secret, and auth_admin_email.
${user_config.auth_mode}is_serverTrue on the ONE machine in your fleet that should ingest and store logs — it runs the syslog receiver (UDP+TCP), the SQLite store, and the MCP HTTP server. False on every other machine that just needs to query logs from Claude Code; those instances skip all local server setup and act as MCP clients only.
${user_config.is_server}batch_sizeNumber of parsed syslog messages written per SQLite batch. Higher values reduce transaction overhead during bursts but can add write latency. Server mode only.
${user_config.batch_size}public_urlPublic base URL for OAuth issuer/resource metadata, e.g. https://syslog.example.com. If auth_mode=oauth and this is empty, setup derives it from an https server_url by stripping a trailing /mcp if present. Server mode only.
${user_config.public_url}server_urlBase URL the MCP client in this Claude Code session connects to (always used — both modes). Server mode: keep the default http://localhost:3100 so the local MCP client talks to the local server. Client mode: set to the remote server, e.g. http://dookie:3100, http://syslog.lan:3100, or https://syslog.example.com if fronted by a reverse proxy. Must include the scheme and (if non-default) port; do NOT include a trailing /mcp path — the plugin appends it.
${user_config.server_url}fleet_hostsHostnames for hosts in your fleet. Used for Docker ingest: when docker_ingest_enabled is true, each entry becomes the docker-socket-proxy URL http://<host>:2375. Entries must be reachable by name — resolvable DNS or an /etc/hosts entry, not just an SSH config alias. Add one entry per host, e.g. dookie, squirts, tootie. Leave empty if you don't use Docker ingest.
${user_config.fleet_hosts}max_db_size_mbSoft cap on logical SQLite DB size. When exceeded, oldest logs (ordered by received_at) are deleted in batches until the recovery target is met; if cleanup can't free enough space, NEW WRITES are blocked until storage recovers. 0 disables this guard entirely (logs grow until disk fills or retention purges them). Default 8192 MB (8 GB) is sized for a homelab ingesting from a handful of hosts plus Docker stdout — bump much higher (50000+) if you have lots of free disk and want long retention, lower if storage is tight. Server mode only.
${user_config.max_db_size_mb}retention_daysAge-based purge: log entries older than this are PERMANENTLY DELETED hourly with no recovery path — back up first with `scripts/backup.sh` if you need archival. 0 disables age-based purging entirely (storage guards from max_db_size_mb still apply). Default 90 days balances forensic value against DB size for a typical homelab. Server mode only.
${user_config.retention_days}auth_admin_emailBootstrap allowed Google account for OAuth mode. The server refuses to start OAuth without an allowlisted account. Server mode only.
${user_config.auth_admin_email}google_client_idGoogle OAuth client ID used when auth_mode=oauth. Create a Web application OAuth client in Google Cloud Console. Server mode only.
${user_config.google_client_id}cortex_receiver_hostInterface address the syslog receiver binds to. 0.0.0.0 listens on every interface so other hosts on the LAN/VPN can forward to you (the normal homelab choice). 127.0.0.1 restricts to local-only ingestion (useful when only this host's rsyslog forwards in). Server mode only.
${user_config.cortex_receiver_host}cortex_receiver_portUDP and TCP port the syslog receiver binds to inside the server process or Docker container (the same port serves both protocols). Keep this at 1514 unless you intentionally grant CAP_NET_BIND_SERVICE or run as root. Server mode only.
${user_config.cortex_receiver_port}google_client_secretGoogle OAuth client secret used when auth_mode=oauth. Stored in the generated plugin env file with mode 600. Server mode only.
${user_config.google_client_secret}docker_ingest_enabledPull container stdout/stderr from remote Docker socket proxies in addition to syslog. When true, each fleet_host is treated as a docker-socket-proxy endpoint at http://<host>:2375 and continuously polled for container logs. Logs land in the DB tagged hostname=<host>, app_name=<container>, source_ip=docker://<host>/<container>/<stream>. Each fleet host MUST be running docker-socket-proxy (or equivalent) on port 2375 with at least containers/logs read access — exposing the raw Docker socket is unsafe. Server mode only.
${user_config.docker_ingest_enabled}write_channel_capacityIn-memory parsed-message queue capacity before listener backpressure. Increase this for bursty senders like journald backfill or high-volume network devices. Server mode only.
${user_config.write_channel_capacity}cortex_receiver_host_portHost port published by Docker Compose to the container's syslog bind port. Set this to 514 when devices can only forward to the privileged syslog port, while leaving cortex_receiver_port at 1514 inside the container. Docker server mode only.
${user_config.cortex_receiver_host_port}auth_allowed_redirect_urisOptional extra non-loopback OAuth client redirect URIs. Setup automatically adds Claude's MCP callback URLs and, when present, the current Codex mcp_oauth_callback_url from ~/.codex/config.toml. Server mode only.
${user_config.auth_allowed_redirect_uris}Rust syslog receiver and MCP server for homelab log intelligence. Ingests syslog over UDP and TCP, stores it in SQLite with FTS5 full-text indexing, and exposes action-based log search, inventory, correlation, status, and analysis tools through MCP, REST, and CLI adapters backed by the shared service layer.
cortex also maintains derived projection tables for future investigation graph features. Those graph tables connect source IPs, claimed hosts, apps, services, containers, AI projects/sessions, and error signatures with evidence, but raw logs, heartbeats, inventory, signatures, and session rows remain the source of truth. The graph projection is rebuildable and intentionally has no ingest triggers. Graph rebuilds use staging tables plus a short serialized swap and record explicit projection status, source watermarks, row counts, runtime metrics, and degraded failure state.
Run the stdio MCP server or CLI without a manual binary install:
npx -y cortex-rmcp --help
MCP clients can use the same launcher:
{
"mcpServers": {
"cortex": {
"command": "npx",
"args": ["-y", "cortex-rmcp", "mcp"]
}
}
}
The npm package downloads the cortex binary from GitHub Releases during postinstall. Cortex keeps its repo and CLI name as cortex; the npm package is cortex-rmcp because Cortex is broader than only an MCP server.
Most Rust MCP servers use:
<service>-rmcpr<service><service>-rmcpCortex is the exception: repo cortex, CLI cortex, npm package cortex-rmcp.
┌─────────────────────────────────┐
rsyslog/syslog-ng ─▶ UDP :1514 / TCP :1514 │
network devices ─▶ ┌──────────────────────────┐ │
│ │ parse → batch writer │ │
│ │ SQLite + FTS5 (WAL mode) │ │
│ └──────────────────────────┘ │
Claude / MCP ◀──── ▶ RMCP HTTP :3100/mcp │
local MCP client ◀──▶ syslog mcp query process │
└─────────────────────────────────┘
The daemon listens on a single port for both UDP and TCP syslog (default 1514). All inbound messages are parsed, batched, and written to SQLite with full-text indexing. The MCP HTTP server runs on a separate port (default 3100) and uses RMCP Streamable HTTP in stateless JSON-response mode. Local stdio-only MCP clients can launch cortex mcp, a query-only MCP process that reads the same SQLite database without starting syslog listeners or the HTTP server.
MCP is an exposure surface, not the owner of log-intelligence business policy. Shared defaults, limits, validation, audit identity, correlation behavior, and safety gates should live in SyslogService or service-owned operation models so MCP, REST, and CLI remain consistent.
One MCP tool, cortex, is exposed. Use the required action argument to run search, filter, tail, errors, hosts, map, sessions, search_sessions, abuse, abuse_incidents, abuse_investigate, ai_correlate, topic_correlate, usage_blocks, project_context, list_ai_tools, list_ai_projects, correlate, stats, status, apps, source_ips, timeline, patterns, context, get, ingest_rate, silent_hosts, clock_skew, anomalies, compare, compose_status, compose_doctor, unaddressed_errors, ack_error, unack_error, notifications_recent, notifications_test, llm_invocations, similar_incidents, incident_context, graph, skill_events, skill_incidents, skill_investigate, mcp_events, mcp_incidents, mcp_investigate, hook_events, hook_incidents, hook_investigate, or help.
For the complete action-specific parameter reference, see docs/mcp/SCHEMA.md. For correlation behavior and AI/non-AI inclusion rules, see docs/mcp/CORRELATION.md.
npx claudepluginhub jmagar/claude-homelab --plugin syslog-mcpQuery, monitor, and manage Unraid servers via GraphQL API through MCP tools. Supports system info, Docker, VMs, array/parity, notifications, plugins, rclone, and live telemetry.
Core homelab agents, commands, and setup/health skills for self-hosted service management. Includes interactive credential setup wizard and unified service health dashboard.
Connects Claude Code to the rustarr MCP server — one tool surface over a media-automation fleet (Sonarr, Radarr, Prowlarr, Tautulli, Overseerr, qBittorrent, SABnzbd, Plex, Jellyfin, and more). Also bundles standalone per-service skills (sonarr, radarr, prowlarr, overseerr, sabnzbd, qbittorrent, plex, jellyfin, tautulli, tracearr, bazarr) that drive each service's REST API directly as an offline fallback when the MCP server is unavailable.
Unraid NAS/homelab monitoring via MCP
SWAG reverse proxy configuration management via MCP. Create, edit, view, and manage nginx proxy configurations with auth integration.
Analyze log files with ctrlb-decompose — pattern clustering, anomaly detection, and severity scoring
Analyze logs for performance insights and issues
14 specialized skills for natural language Splunk automation - search, job management, exports, and administration via Claude Code
Connect Claude to your Windows PC's AppControl monitor — query running processes, tracked binaries, resource usage history, security events, and idle/uptime intervals.
Set up and use Gonzo, the open-source terminal log analysis tool. Detects deployment platforms (Vercel, Supabase, K8s, Docker, AWS, Cloudflare, Fly, Render, Railway, Netlify), generates the right pipe command with platform-specific normalizers, and configures AI analysis. Use when the user wants to tail, watch, stream, or analyze logs in their terminal.
Auto-capture development command output and search/analyze with Claude Code