Splunk MCP server only returns status and result count

[nonno_pinto]

I've been trying to use Splunk MCP Server on multiple server installations and MCP clients and I'm having the same issue on all scenarios: MCP server only returns a status and a count of the results, not results themselves.

Splunk MCP Server:

1.

Splunk Enterprise (on Linux Ubuntu)
Version: 10.0.1

Splunk MCP Server: v.  1.0.1

2. 

Splunk Cloud
Version: 10.1.2507.15

Splunk MCP Server: 1.0.1

Both case I have AI toolkit and AI Assistant for SPL installed and updated to latest versions.

MCP clients:

1. Gemini CLI

2. Claude Desktop

3. MCP client on n8n running as docker on a local Linux machine

The issue is always the same: everything works, BUT the MCP server doesn't return a JSON with results, just the status of the request and a result count. When working with LLMs (Gemini and Claude), they make up some data; but if you ask for the raw response, you see there is no data except for status and count. 
I've worked a little on mcp server code and I've noticed a couple things:

• MCP server appears to return the full data, or at least it has the function needed to do so
• MCP server has a function to set logging DEBUG mode, but no instruction on how to use it and no settings on app UI. I've managed to set DEBUG mode only changing the code

Has anyone had the same problems and managed to fix them?

UPDATE: I've tested Splunk MCP server 1.0.1 working with codex CLI. Updating to 1.0.2 it also works with Gemini CLI, i think due to this fix they introduced:

• Fix: Mirrors the structuredContent field payload to the content text field.

[TravellingGuy]

There's a new version of the MCP Server (1.0.2) that fixes the issue.

[samal]

I can't speak to anything but Claude but this works in Claude Code CLI.  It does not work in Claude Desktop.  When asking Claude desktop for an explanation I get the following:

The core difference comes down to how MCP tool results are surfaced in each environment:
Claude Code CLI runs in a terminal context where MCP tool responses come back as raw structured data (JSON, text, etc.) directly in my context window. I can read every field, every value — the full payload.
Claude in the web interface (me, right now) integrates MCP servers differently. The tool results appear to be getting summarized or only partially surfaced — I can see metadata like "Tool executed successfully (1 result)" but the actual row data and field values aren't being passed through to me in a readable way. I know that a query ran and how many rows came back, but I can't read what's in those rows.
It's essentially a display/integration layer issue specific to how the claude.ai web UI handles MCP tool responses compared to Claude Code's terminal-native integration, which gives full fidelity access to the raw output.
So it's not a capability gap on my end — it's an artifact of how MCP results are being piped into my context in this particular interface. If you're doing heavy Splunk work via MCP, Claude Code CLI is genuinely the better tool for that workflow right now. You could also feed me query results directly by pasting them into the chat, and I can analyze them just fine that way.

Although it refers to itself as running in the web interface, I'm assuming that's just because claude desktop is a wrapped web app.

[TravellingGuy]

I'm seeing this as well in Windsurf, with any of the models I choose.

Curiously, Zed seems to to be fine with it and properly gets the full results.

I also upgraded from the beta release (it was a pre-1.0 release, I don't specifically remember the version) and that worked fine, never had this issue, so this is new in the 1.0 release cycle.

[nonno_pinto]

What configuration are you using on Zed? I've been trying both a cloud and a local Splunk env and both return "Context server request timeout"

First time using Zed, then maybe I'm missing something very stupid.

[TravellingGuy]

Here's my MCP config in Zed:

    "splunk-mcp-server": {
      "enabled": true,
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://<URL>:8089/services/mcp",
        "--header",
        "Authorization: Bearer <token>"
      ],
      "env": {}
    },

It works with the Claude and Codex CLI external agents. Haven't tried the Zed agent.

[nonno_pinto]

Thanks. I've configured the MCP in zed and tried with Claude Sonnett 4.6 model but still get the same problem.

Could you please share the MCP server version you are using,  the model you are using in zed and an example of request and full response? Maybe just some tool have this issue and I'm trying only th bugged ones.

[TravellingGuy]

Hi. It's the most recent MCP server release, 1.0.1.

I've tried with both the Claude Agent and Codex CLI external agents, and it works with any of the models I've tried (including Sonnet 4.5, Haiku 4.5, Opus 4.5, and gpt-4.1). I should note, once difference I have is I'm accessing these models through Azure AI Foundry. That could potentially be a difference.

[kundeng]

You actually seeing there results and not just a status message and result count?  

[nonno_pinto]

Or maybe the model sees the result count and just create the response? To me, it happens with every model I've tried except for GPT.

[nonno_pinto]

Please, don't hold it against me, but could you share a raw request and a raw response, anonymized? Because I'm missing something...

[TravellingGuy]

Here's a screenshot showing my request and the initial response, and it proceeds to display all of my indexes....and no, it's not hallucinating, they are our indexes, including test ones we've created.

I've also made similar queries around data models, and it goes and collects them fine.

I don't know what to tell you. Maybe it's something to do with Azure AI Foundry, who knows.

[kundeng]

It works with codex but fails with windsurf. 

windsurf with any LLM will hallucinate a list.

codex CLI works. 

[nonno_pinto]

I can confirm that with Codex CLI it works fine. Sometimes i have a truncate response that I'm investigating, but at least the partial answer is correct.

[robsharp]

I was having the same problem and claude helped me fix it. 

There is a bug in the mcp_message.py file

From Claude not me below.

The actual results are being put in structuredContent, but the MCP client (me) only reads the content field — which just contains the short summary text like "Tool executed successfully (24 results)." That's literally all I've been receiving!

sed -i 's/"text": summary}/"text": json.dumps(structured, indent=2)}/' \
  /app/splunk/etc/apps/Splunk_MCP_Server/bin/mcp_message.py

[nonno_pinto]

I gave a look to the standard MCP server definition and I must admit that that's not an error, Splunk is just following the suggested standard.

Structured content is returned as a JSON object in the structuredContent field of a result.
For backwards compatibility, a tool that returns structured content SHOULD also return the serialized JSON in a TextContent block.

It should also return same content in the result field, but it's not mandatory at all (source: MCP protocol ).

This makes things harder, if possibile. 

[robsharp]

yeah I did a little more reading based on your comment.  It seems like claude desktop just doesn't want to use that structuredcontent responses.   Not sure if it's a disagreement amongst various factions as the MCP is standardized or what.  Asking claude this question and it says it won't use structuredcontent for "now".

[nonno_pinto]

There are a couple problem on this point:

1. it's not just Claude, it's also Gemini CLI and MCP client on n8n
2. most important, in my understanding mcp standard is mainly sponsored by Anthropic, then why Claude should not follow the standard?

[kundeng]

splunk please hire some good testers (and programmers).