@pooml/mcp
# @pooml/mcp
MCP server for [pooml](https://github.com/n0rdy/pooml): query your logs and
metrics with plain SQL from Claude, or any other MCP client.
Runs on your machine (stdio), talks to your pooml instance over its
read-only [query API](https://github.com/n0rdy/pooml#query-api-sql-over-http).
Your credentials stay local; the pooml server needs nothing MCP-specific.
## Tools
- `query_logs` - SQL over the logs (levels, services, full-text search via FTS5)
- `query_metrics` - SQL over the metrics (counters and gauges)
- `list_metrics` - what metrics exist, so the model doesn't guess names
Strictly read-only: every query goes through pooml's layered SQL validation
(SELECT-only, allow-listed tables, read-only connection, timeouts, row caps).
## Setup
1. On the pooml server, enable the query API:
`POOML_QUERY_API_ENABLED=true` and `POOML_QUERY_API_AUTH_SECRET=<min 32 chars>`.
2. Add to your MCP client. For Claude Code:
```bash
claude mcp add pooml \
-e POOML_URL=https://your-pooml-host:8080 \
-e POOML_QUERY_API_AUTH_SECRET=your-query-secret \
-- npx -y @pooml/mcp
```
Or in `.mcp.json`:
```json
{
"mcpServers": {
"pooml": {
"command": "npx",
"args": ["-y", "@pooml/mcp"],
"env": {
"POOML_URL": "https://your-pooml-host:8080",
"POOML_QUERY_API_AUTH_SECRET": "your-query-secret"
}
}
}
}
```
If pooml sits behind a Cloudflare Tunnel with Access, add the service token:
`POOML_CF_ACCESS_CLIENT_ID` and `POOML_CF_ACCESS_CLIENT_SECRET`.
## Why SQL
pooml's whole pitch is that your observability data is SQLite queried with
SQL - and LLMs already speak SQL fluently. No custom query language for the
model to hallucinate around: it writes `SELECT service, COUNT(*) FROM logs
WHERE level >= 4 ...` and gets answers.
## License
[Apache-2.0](./LICENSE)
TDQS
Scored across 3 tools
Each tool targets a clearly distinct function: query_logs handles log data, query_metrics handles metric data, and list_metrics provides metadata discovery for metrics. There is no meaningful overlap or ambiguity between them.
All tool names follow the consistent verb_noun pattern: query_logs, list_metrics, and query_metrics. The use of 'list' for discovery and 'query' for SQL access is a clear and predictable convention.
Three tools is well-scoped for a read-only observability server: one for logs, one for metric metadata, and one for metric data. Each tool provides substantial functionality, so the count feels appropriate rather than thin.
The tool surface covers the stated domain completely: log querying, metric listing, and metric querying are all present with rich SQL capabilities. No obvious gap exists for the read-only observability purpose this server appears to serve.