Splunk MCP Server returns fabricated/hallucinated data with Claude Desktop

[MaverickT]

Hi everyone,

I've been testing the official Splunk MCP Server app from Splunkbase with Claude Desktop and noticed a concerning issue — the MCP server intermittently returns completely fabricated data instead of actual query results.

Environment:

• Splunk Enterprise 10.2.0 on Linux
• Official Splunk MCP Server from Splunkbase, version 1.0.0
• Claude Desktop as MCP client

What I'm seeing:

When running tstats queries against datamodels (Authentication, Endpoint.Processes), the results returned via MCP sometimes contain plausible-looking but completely fake data — usernames that don't exist, wrong countries, incorrect counts.

Examples:

• Query for failed auth by user returned "james.smith", "j.smith", etc. — users that don't exist in my environment
• Query for failed auth by country returned Russia and China — actual data shows Nigeria and Albania
• Same query run multiple times returns different fabricated data, then sometimes the correct data

Pattern observed:

• Simple/fast queries (index lists, basic stats) → Usually correct
• Zero-result queries → Correct (returns empty)
• Complex datamodel queries → Intermittent fabrication
• Re-running the same query → Sometimes fixes it, sometimes returns different fake data

My suspicion:

The MCP server documentation mentions guardrails including a 1-minute timeout. When queries timeout, instead of returning an error, something appears to be generating fake "plausible" responses. This could be an LLM component filling in the blanks.

Questions:

1. Has anyone else experienced this behavior?
2. Is there an LLM/AI component in the MCP server that generates responses on timeout/failure?
3. Is there a way to disable any fallback response generation and just return errors?
4. Are there logs I can check to see what's happening when this occurs?

This is a critical issue - we can't have a tool silently returning fake data that looks real. I'd rather get an error than incorrect results.

Thanks for any insights!

[pedro_chicago]

I have experienced the same thing.  The results presented by Claude Desktop are mostly inaccurate; however, it sometimes combines some valid field values.  For example, the splunk_get_info tool data is completely wrong, while the splunk_get_knowledge_objects for type=apps returns an inaccurate list of apps but specifies a valid splunk_server value.

If I look in the Claude MCP logs, it does show a truncated entry with correct values.  Claude Desktop just doesn't use that data in what it returns in the UI.

I set up the MCP in Claude Code, and everything is returned correctly.  I wondered if this was because it was using Opus as opposed to Sonnet in Claude Desktop.  I tried using Opus in Claude Desktop but still got the same hallucinatory data returned.  This makes it seem more like a Claude Desktop issue as opposed to an LLM issue, but I am not really sure.

We are using Splunk Cloud.  I don't know if this is a coincidence or just bad timing, but it seemed to work OK with the previous versions of Splunk MCP before version 1.x with the MCP hosted separate from our SHC with a URI if https://[stack].api.scs.splunk.com/[stack]/mcp/v1/.  I may try using that old URI to see if it still works and has the same issues.

If I have time I am going to try some other MCP Clients to see if they behave the same way.

I will post any findings here.

[livehybrid]

Hi @MaverickT 

The MCP server itself doesnt have LLM connectivity, therefore it will be the LLM you are using which is doing the hallucinating! You may need to rework your prompt to ensure that it only uses actual data returned from Splunk MCP server.

🌟 Did this answer help you? If so, please consider:

• Adding karma to show it was useful
• Marking it as the solution if it resolved your issue
• Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing

[MaverickT]

Many thanks @livehybrid, you pointed me at the right direction, the MCP server returns  the following:

2026-02-10T22:43:24.467Z [splunk-mcp-server] [info] Message from server: {"jsonrpc":"2.0","id":6,"result":{"content":[{"type":"text","text":"Tool executed successfully (1 result)."}],"structuredContent":{"results":[{"src":"USERS-MAC","count":"5"}],"truncated":false,"total_rows":1}}} { metadata: undefined }

As it turns out, Claude ignores what is returned as structuredContent. It only sees what is in the "content".  This is Claude's bug, MCP works like it should.

---

[nonno_pinto]

I'm having same issue. Trying to troubleshoot the problem I took a look to the code and set log to debug mode and wrote a new log that returns the full response.

For debug mode (there's also a function, but still haven't managed how to use it):

logging_config.py

function set_debug_mode

change both logging.INFO to logging.DEBUG

To print the whole json response:

function _build_response

set a custo log like this one "logger.DEBUG("GZ: full payload response %s", payload_obj)"

It workend on my on prem env, still haven't tried on cloud

[MaverickT · Accepted solution]

On February 27. Splunk MCP Server 1.0.2 was released that fixes this issue.

What's New (Build 1.0.2)

• Fix: Handles a race condition while creating a new secret for token encryption.
• Fix: Mirrors the structuredContent field payload to the content text field.
• Enhancement: Adds support for configuring an MCP URL using port 443.