Read-only log search over an Elasticsearch cluster you already run. NetClaw installs no cluster and indexes nothing — this queries what is already there.
Server: elasticsearch-mcp (adopted, docker.elastic.co/mcp/elasticsearch, Apache-2.0,
digest-pinned) · 5 tools · 1,094 tokens
The rule that matters most
A bare
searchtotal is capped at 10,000 and reads as if it were exact.
Elasticsearch stops counting at 10,000 and marks the total relation: "gte" — meaning at
least. This server discards that qualifier and prints Total results: 10000. There is
nothing in the response to tell you the number is a floor.
Measured against 10,075 real documents:
| How you ask | What you get |
|---|---|
search with no guard |
Total results: 10000 — wrong |
search with "track_total_hits": true |
Total results: 10075 — correct |
esql STATS COUNT(*) |
10075 — correct |
On a million-document index a bare search still says 10,000. The error is unbounded and invisible.
Therefore, for any question of the form "how many", "how often", "which is most", or any number a human will act on:
- Use
esqlwithSTATS COUNT(*), or - Use
searchwith"track_total_hits": truein thequery_body.
search without that guard is for retrieving example documents only — never for counting.
If you report a total that came from an unguarded search, you are reporting a number that may
be arbitrarily wrong.
Tools
| Tool | Use it for | Required arguments |
|---|---|---|
list_indices |
what indices exist, and their document counts | index_pattern (use *) |
get_mappings |
field names and types before writing a query | index |
search |
retrieving matching documents (Query DSL) | index, query_body |
esql |
counting, aggregating, grouping, ranking | query |
get_shards |
shard health when results look incomplete | — |
Note the argument names are snake_case (query_body, index_pattern). Wrong names fail
loudly with a deserialization error — they are not silently ignored.
Worked patterns
How many errors, by device — a counting question, so ESQL:
esql: FROM netclaw-syslog | WHERE severity == "error" | STATS n = COUNT(*) BY device | SORT n DESC
Show me examples of those errors — a retrieval question, so search:
search: index=netclaw-syslog
query_body={"query":{"term":{"severity":"error"}}, "size":20, "track_total_hits":true}
What am I even working with — always start here on an unfamiliar cluster:
list_indices: index_pattern=*
get_mappings: index=<the one you picked>
Guessing field names is the most common cause of a query that returns nothing. A term query
against a text field, or an aggregation on one, will not behave as expected — check the
mapping first. Fields are commonly foo (analysed text) plus foo.keyword (exact); use
.keyword for grouping, sorting, and exact matches.
Empty is not the same as zero
A query returning no hits means this query found nothing. It does not establish that the event did not occur. Before reporting "no errors", confirm:
- the index actually holds data for the time range (
list_indicesdoc counts, or an ESQL count with no filter) - the field names came from
get_mappings, not from a guess - the time range matches how the data is actually timestamped
Say "no matching events in <index> for <range>" — not "no errors occurred".
Boundaries — which backend answers
NetClaw has several log and metric backends. Pick by where the data lives, not by question shape:
| Backend | Use when |
|---|---|
| this skill | logs indexed in Elasticsearch / ELK |
splunk-search |
logs in Splunk |
datadog-logs |
logs in Datadog |
gcp-cloud-logging |
Google Cloud audit/platform logs |
prometheus-monitoring / grafana-observability |
time-series metrics, not logs |
duckdb-analysis |
exported files on disk (CSV/Parquet/JSON), not a live store |
If you do not know where the logs live, ask. Do not query every backend hoping one answers — an empty result from the wrong store is indistinguishable from an absence of events.
Read-only
All five tools read. There is no index, update, delete, or reindex verb in the manifest, so no
write is reachable regardless of the credential. Prefer an Elasticsearch API key with
read/view_index_metadata only — the server will happily use a superuser credential, and
nothing in it needs one.
Configuration
| Variable | Meaning |
|---|---|
ES_URL |
cluster URL as reached from inside the container — a cluster on this host is http://host.docker.internal:9200, not localhost |
ES_API_KEY |
API key (preferred) |
ES_USERNAME / ES_PASSWORD |
basic auth alternative |
ES_SSL_SKIP_VERIFY |
true to skip certificate verification (lab only) |
Upstream status
This server is deprecated by Elastic and receives critical security updates only. It was
adopted deliberately: its replacement, Agent Builder's MCP endpoint, is Enterprise-tier on
self-managed, so the supported path is paywalled while this one is Apache-2.0, already
published, and works against a free Basic cluster. The image is digest-pinned so a
security-only update cannot change answers underneath you. See
specs/096-elastic-logs/spec.md.