Cortex RMCP is a Rust-implemented MCP server designed for homelab environments. It connects AI agents to log infrastructure covering syslog sources, Docker container logs, and general homelab log streams. The server provides full-text search (FTS) over those log sources, allowing agents to query and retrieve relevant log entries without manual log parsing. It also supports AI transcript correlation, which means agents can cross-reference conversation or inference transcripts against log data to trace events or debug issues. The server communicates over stdio transport and is distributed via the npm registry at version 3.9.1. Configuration is handled through environment variables: CORTEX_HOME and CORTEX_TOKEN or CORTEX_API_TOKEN set access credentials and home directory, while CORTEX_RMCP_VERSION, CORTEX_RMCP_REPO, and CORTEX_RMCP_RELEASE_BASE_URL control which binary release is fetched. RUST_LOG controls logging verbosity for the server process itself. No tools are declared in the registry record, so the exact callable surface is not publicly enumerated. This server is a fit for developers running self-hosted infrastructure who want an agent to search and correlate logs programmatically. It is not designed for cloud-managed logging platforms or databases outside its homelab log scope.
Cortex RMCP
Rust MCP server for homelab logs, syslog, Docker logs, FTS search, and AI transcript correlation.
Use cases
- Search Docker container logs using full-text queries from an AI agent
- Correlate syslog entries with AI-generated transcripts to trace system events
- Automate log triage across multiple homelab services without manual log review
- Configure log ingestion sources via environment variables for a self-hosted setup
- Debug homelab incidents by letting an agent query structured and unstructured log data
When to use it
- When running a self-hosted homelab that produces syslog or Docker container logs
- When an AI agent needs full-text search across local log sources
- When transcript-to-log correlation is needed for debugging or auditing
- When stdio transport is acceptable for the agent runtime
When not to use it
- When targeting cloud-managed logging services such as Cloudwatch or Datadog
- When the agent runtime requires a non-stdio transport
- When a declared, enumerated tool surface is required — no tools are listed in the registry record
- When the deployment environment is not a homelab or self-hosted infrastructure