Support for multiple log files in the nodes_log query

[ngopalak-redhat]

Summary

Enhanced the nodes_log MCP tool to accept multiple log queries in a single call, reducing the number of round trips between the MCP client and server when analyzing node logs from multiple files.

Previously, fetching logs from multiple node sources (e.g., kubelet and crio) required multiple separate MCP tool invocations. While the underlying Kubernetes API (/api/v1/nodes/{name}/proxy/logs) is designed for single log file access, this creates friction at the MCP layer where users want to analyze logs holistically.

Pain points with the old approach:

• Multiple MCP calls needed to gather logs from different sources (kubelet, crio, kube-proxy, etc.)
• Increased overall latency

Solution

Modified the query parameter to support both single string and array of strings using JSON Schema's oneOf:

  "query": {
      OneOf: []*jsonschema.Schema{
          {
              Type:        "string",
              Description: `Single query specifying a service or file...`,
          },
          {
              Type:        "array",
              Description: `Array of queries specifying multiple services or files...`,
              Items: &jsonschema.Schema{Type: "string"},
          },
      },
  }

• Single API call for multi-file analysis: Fetch kubelet, crio, and kube-proxy logs in one request
• Better context for LLMs: All related logs arrive together
• When rolling out patches to multiple components, get all relevant logs at once
• Backward compatible: Existing single-query usage continues to work unchanged

Additional Fixes

• Updated example documentation to remove /var/log prefix (e.g., kubelet.log instead of /var/log/kubelet.log) since the Kubernetes API automatically adds this prefix

Testing

⏺ kubernetes-local-mcp-server - Node: Log (MCP)(name: "ip-10-0-32-244.ec2.internal", query: ["audit/audit.log","ovn/acl-audit-log.log","ovn/ovsdb-server-nb.log"],
                                                tailLines: 0)
  ⎿  ⚠ Large MCP response (~28.5k tokens), this can fill up context quickly
  ⎿ === Logs for query: audit/audit.log ===
    type=DAEMON_START msg=audit(1761707258.843:1666): op=start ver=3.1.5 format=enriched kernel=5.14.0-570.55.1.el9_6.x86_64 auid=4294967295 pid=1781 uid=0 s
    es=4294967295 subj=system_u:system_r:auditd_t:s0 res=successAUID="unset" UID="root"
    … +1025 lines (ctrl+o to expand)

[Cali0707]

Changes like this are where I personally would like to see some form of evals to see if this does actually improve the LLMs performance, especially compared to just having an array, and not treating the single query as a separate case.

Since we should have some basic evals in CI here in a few days, coming from https://github.com/genmcp/gevals, can we hold off on merging this until we see eval results?

Any opinions @matzew @manusa ?

[manusa]

I had this one in my queue to do some tests locally.
It's not only evals, but many agents are able to call multiple tools (or multiple invocations of the same tool) in parallel.
I'm not sure if implementing the funnel ourselves would be helpful.

[ngopalak-redhat]

My goal was to fetch the same set of 10 log files from 10 different nodes. This PR allows us to make 10 calls instead of 100 (10 nodes X 10 files each). Since this is a deterministic and repeatable task, implementing it in the MCP server made sense to me. Also MCP server would run remotely beside the kubernetes cluster and hence reducing the number of calls made from clients.