Ankra

query_logs

Read-only

Search historical logs across pods and restarts in a connected or Ankra hosted store (Loki, Elasticsearch, OpenSearch, VictoriaLogs). get_pod_logs reads one live pod. Use structured filters (namespaces/pods/containers plus a text search) or raw_query for a provider expression (LogQL on Loki, a JSON query-DSL clause on Elasticsearch/OpenSearch, LogsQL on VictoriaLogs). Results are normalized {timestamp, line, labels, fields} entries, newest first by default, truncated to the limit. Every result carries cluster_attribution, because one log store can be shared by several clusters (the Ankra platform clusters ship their platform namespace into the same OpenSearch indices with identical pod names): when the store attributes lines to clusters (a cluster field on Elasticsearch/OpenSearch, a cluster stream label on Loki, stamped by the shipper) the query is scoped to this cluster's value, and lines attributed to other clusters or carrying no attribution are excluded and counted (other_clusters_hits, unattributed_hits; absent when the store cannot count them). cluster_attribution.state is "attributed" (scoped; this cluster's lines exist in the window), "requested_absent" (the store attributes other clusters' lines but none in the window carries this cluster's value - the result is empty and nothing in the store can be attributed to this cluster; report that, never substitute unattributed lines), or "none" (no line in the window carries the field; the result is NOT scoped and, if the store is shared, may include other clusters' lines - say so). Relay the note. On a scoped Loki store raw_query is refused; use the structured filters, which are scoped automatically. On Elasticsearch/OpenSearch each entry's fields object carries the requested extra _source paths (default: level and extra, the platform's structured-attribute container - cluster_id, error, etc.); pass fields to pick different paths. Attributes indexed as flat_object match on exact full leaf values only, via dotted paths in raw_query (e.g. {"match": {"extra.cluster_id": ""}}) - substring search inside attribute values is not supported by the store. total_hits_relation says how to read total_hits: "eq" means it is the exact number of matches, "gte" means the store stopped counting (Elasticsearch and OpenSearch cap at index.max_result_window, 10,000 by default) and total_hits is only a floor - in that case say "at least N", never state it as the exact count. Use this for 'what errored around 14:00', cross-pod correlation, and logs from restarted/deleted pods. group_by="signature" answers 'what errored in this window' without the error text: errors grouped into signatures (container, normalised message, count, first/last seen, sample, history new/recurring/unknown vs the prior 7 days; never call unknown new). counts_are_exact false means counts are floors. Read-only.

Input Schema

Name	Required	Description
`end`	No	RFC3339 window end (default now).
`pods`	No	Only logs from these pod names.
`limit`	No	Max log lines to return (default 100, max 200).
`since`	No	Look-back window, e.g. '15m', '1h', '24h', '7d' (default 1h). Ignored when start is set.
`start`	No	RFC3339 window start, e.g. 2026-01-02T14:00:00Z.
`fields`	No	Extra _source paths to return per entry on Elasticsearch/OpenSearch, dotted paths allowed (e.g. 'extra.cluster_id'). Default: level, extra. Ignored on Loki.
`search`	No	Case-sensitive substring the log line must contain.
`source`	No	auto (default): connected, then hosted if absent. Explicit choices never fall back; match queries and labels.
`group_by`	No	signature: group errors into signatures instead of returning lines.
`direction`	No	backward = newest first (default), forward = oldest first.
`min_level`	No	Only lines whose severity field is at or above this (default error with group_by, none on a raw_query read). Not with raw_query.
`raw_query`	No	Provider query expression instead of the structured filters: a LogQL expression on Loki (e.g. {namespace="payments"} \|= "timeout"), a JSON query-DSL clause on Elasticsearch/OpenSearch (e.g. {"match_phrase": {"message": "timeout"}}), a LogsQL expression on VictoriaLogs (e.g. _msg:~"timeout" \| stats by (kubernetes.pod_name) count()). The time range still applies.
`cluster_id`	Yes	Ankra cluster id (UUID) the call targets. Discover ids with list_clusters.
`containers`	No	Only logs from these container names.
`namespaces`	No	Only logs from these namespaces.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

changedInput schema / properties / min_level / description

Previous value: -"Only lines whose severity field is at or above this. With group_by it defaults to error, except on a raw_query read, which gets no default and keeps its own conditions. Not with raw_query."New value: +"Only lines whose severity field is at or above this (default error with group_by, none on a raw_query read). Not with raw_query."

Changed1 schema field changedOct 20, 2026

changedInput schema / properties / min_level / description

Previous value: -"Only lines whose severity field is at or above this (default error with group_by). Not with raw_query."New value: +"Only lines whose severity field is at or above this. With group_by it defaults to error, except on a raw_query read, which gets no default and keeps its own conditions. Not with raw_query."

Changed2 schema fields changedOct 19, 2026

addedInput schema / properties / group_by

Added value: +{
+  "description": "signature: group errors into signatures instead of returning lines.",
+  "enum": [
+    "signature"
+  ],
+  "type": "string"
+}

addedInput schema / properties / min_level

Added value: +{
+  "description": "Only lines whose severity field is at or above this (default error with group_by). Not with raw_query.",
+  "enum": [
+    "warning",
+    "error",
+    "critical"
+  ],
+  "type": "string"
+}

Changed1 schema field changedOct 14, 2026

addedInput schema / properties / source

Added value: +{
+  "description": "auto (default): connected, then hosted if absent. Explicit choices never fall back; match queries and labels.",
+  "enum": [
+    "auto",
+    "connected",
+    "ankra_hosted"
+  ],
+  "type": "string"
+}

First observedOct 10, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare only readOnlyHint, and the description goes far beyond that: cluster-attribution scoping rules, the meaning of other_clusters_hits/unattributed_hits, the three cluster_attribution.state values and the required reporting behavior for each, raw_query refusal on scoped Loki, and total_hits_relation semantics with the 10k cap floor. These are non-obvious operational traits the annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the get_pod_logs contrast are front-loaded, and nearly every sentence carries real information given the multi-backend complexity. It is still a very dense single block, and the repeated imperative asides ('Relay the note', 'say so', 'never call unknown new') add length that bullet structure could tighten.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter, no-output-schema tool, the description covers what an agent otherwise could not infer: return shape ({timestamp, line, labels, fields}), newest-first default ordering, truncation to limit, attribution scoping, and count-accuracy semantics. Nothing needed to call it correctly or interpret results is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description adds genuine meaning beyond the schema: raw_query's per-provider syntax and the fact the time range still applies, fields default of level/extra, min_level's interaction with group_by/raw_query, and default direction/ordering. It leaves some per-parameter details to the schema, keeping it short of a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (search historical logs across pods and restarts) and names the supported backends (Loki, Elasticsearch, OpenSearch, VictoriaLogs). It explicitly distinguishes itself from sibling get_pod_logs ('reads one live pod'), so an agent can route between the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use cases ('what errored around 14:00', cross-pod correlation, logs from restarted/deleted pods) and states the alternative: get_pod_logs for a single live pod. It also spells out when to prefer structured filters vs raw_query, including the condition where raw_query is refused (scoped Loki), which is exactly the decision an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Ankra tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?