How-To: Add Splunk MCP via the Frontier MCP Registry

Federate a third-party (non-organic) MCP server — Splunk’s official MCP app — into the Federal Frontier Platform through the Frontier MCP Registry (Wanaku), and let Frontier agents query Splunk with natural language. The template for onboarding any compliant MCP server.

How-To: add Splunk (and its MCP server) to the platform

This guide does two things at once. Concretely, it shows how to bring Splunk and the official Splunk MCP server into the Federal Frontier Platform so that Frontier agents can investigate security and IT-operations questions with natural language. More broadly, it demonstrates the platform’s most important extensibility property:

Onboarding an MCP server is configuration, not code. The Frontier MCP Registry — the platform’s MCP federation layer (built on Wanaku) — makes any MCP-compliant endpoint (one of our own pods, a SaaS endpoint, or a vendor app like Splunk’s) available to every Frontier agent by registering it as a forward. No image to build, no code to write.

Organic vs. federated MCP servers

The platform runs ~16 organic MCP servers — standalone pods we build and ship (FFO, Kolla, OpenStack, Grafana, Keycloak, Ceph, ArgoCD, Gitea, …). But not every capability needs to be home-grown. The Frontier MCP Registry also federates external MCP servers that we don’t build or host:

• Atlassian — Atlassian’s hosted MCP endpoint, federated for Jira/Confluence.
• Splunk (this guide) — Splunk’s MCP app, hosted on a customer’s Splunk.

Both are reached through the same Frontier MCP Registry the organic servers use, so agents see one unified tool surface regardless of where a server actually runs.

What the Splunk MCP server actually is

The Splunk MCP server is a Splunk App (Splunkbase app 7931), installed into a running Splunk Enterprise or Splunk Cloud instance — not a standalone container. Once installed it registers a persistent REST handler that exposes a fully MCP-compliant endpoint (JSON-RPC 2.0: initialize, tools/list, tools/call; application/json and SSE) at:

POST https://<splunk-host>:8089/services/mcp

Its tools are curated SPL (Splunk Processing Language) queries — defined in builtin_tools.json plus admin-managed custom tools — executed against indexed data. It ships with a token-based auth model, SAFE_SPL query validation, and rate limiting, which makes it a safe surface to expose to autonomous agents.

Prerequisite, stated plainly: this requires a Splunk you can install an app on. It is a bring-your-own-Splunk integration. If a deployment has no Splunk, this guide is not the way to get log analytics — and it is not the right tool for network-policy-drop observability (use a blackbox prober for that). Where a customer already runs Splunk — common in federal/DoD, where Splunk is FedRAMP-authorized — this is a high-value, low-effort win.

Prerequisites

• A reachable Splunk Enterprise/Cloud instance with admin rights to install an app and create a service account/token.
• The Splunk MCP app package (Splunkbase 7931).
• Network reachability from the cluster (Wanaku / Compass API) to the Splunk management port (8089).
• Vault + ESO available for the Splunk token (see Secrets Management).

Step 1 — Install and configure the Splunk MCP app

1. In Splunk, install the Splunk MCP app (Apps → Manage Apps → Install from file, or via Splunkbase).
2. Create a least-privilege Splunk role/service account for agent access — grant only the indexes and search capability the tools need.
3. Configure the app’s tool set: keep the built-in SPL tools that match your use cases (security, performance, data-analysis categories) and add custom SPL tools as needed. Each tool is a vetted SPL template — agents cannot run arbitrary SPL beyond what SAFE_SPL permits.
4. Generate the app’s MCP access token and note the endpoint.

Step 2 — Verify the MCP endpoint

From a host that can reach Splunk, confirm the server speaks MCP:

# initialize
curl -sk -X POST https://<splunk-host>:8089/services/mcp \
  -H "Authorization: Bearer <splunk-mcp-token>" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}'

# list tools (the SPL-backed tool catalog)
curl -sk -X POST https://<splunk-host>:8089/services/mcp \
  -H "Authorization: Bearer <splunk-mcp-token>" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'

A valid initialize result and a populated tools/list confirm it’s ready to federate.

Step 3 — Store the Splunk token in Vault (ESO)

Keep the token out of Git. Write it to Vault and materialize a Kubernetes Secret with External Secrets Operator (same pattern as every other platform secret):

vault kv put secret/wanaku/splunk-mcp token='<splunk-mcp-token>'

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: splunk-mcp-token
  namespace: f3iai
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: ClusterSecretStore
    name: vault-backend
  target:
    name: splunk-mcp-token
    creationPolicy: Owner
  data:
    - secretKey: token
      remoteRef:
        key: wanaku/splunk-mcp
        property: token

Step 4 — Allow egress to Splunk (NetworkPolicy)

The pod network denies by default. Allow the Frontier MCP Registry (and the Compass API, if it calls directly) egress to the Splunk management port. Egress is open unless a pod is already selected by an egress policy — see Network Policy Architecture for the model. If the Registry is egress-restricted, add the Splunk host:8089 to its allowed destinations.

Step 5 — Register the forward in the Frontier MCP Registry (the federation step)

This is the step that makes Splunk appear to every agent. In the Frontier MCP Registry (Wanaku), register the Splunk MCP endpoint as a forward, exactly as the organic servers and Atlassian are registered — point it at the Splunk MCP URL and attach the bearer token. After registration, the Splunk tools show up in the Registry’s tool catalog alongside everything else, and the catalog count rises by the number of SPL tools exposed.

The forward is just a named pointer: name + MCP URL + auth. That is the entire “integration” — the reason a third-party MCP server is config, not code.

Step 6 — Register in Compass so agents discover it

Add the server to the Compass mcp_servers registry (Postgres) so the Compass API discovers its tools at startup and the LLM can select them. Follow the standard MCP server registration checklist (the same one used for organic servers). Once registered, the Splunk tools are part of the agent tool surface.

Step 7 — How Frontier agents use it

From the operator’s perspective it’s just natural language. The agent loop:

Operator question
   → Compass/agent sends the message + tool catalog to the LLM
   → LLM selects a Splunk MCP tool and fills arguments
   → call routed via the Frontier MCP Registry → Splunk MCP app → SAFE_SPL → SPL runs in Splunk
   → results returned → LLM summarizes for the operator

Example prompts a Frontier agent can now answer (mirroring Splunk’s own AI/MCP use cases for IT ops and security investigations):

• “Show failed login spikes in the last 24h by source IP.”
• “Which hosts stopped sending logs in the last hour?”
• “Summarize the top error signatures for the payments app today.”
• “Correlate this alert’s timeframe with authentication anomalies.”

The agent never writes raw SPL — it invokes the vetted, SAFE_SPL-guarded tools the Splunk admin published.

Security & compliance notes

• Token in Vault, never in Git (Step 3). Rotate in Vault; ESO re-materializes.
• Least privilege in Splunk — scope the agent’s Splunk role to only the indexes/capabilities the tools require.
• SAFE_SPL + rate limits in the app bound what agents can execute.
• FedRAMP — Splunk’s authorization status makes this palatable in federal environments where Splunk is already the SIEM of record.
• Audit — Splunk logs every MCP tool invocation in _internal, giving a full audit trail of agent activity.

The takeaway

Splunk is the second federated (non-organic) MCP server on the platform, after Atlassian. Adding it required no new container and no new code — just a verified MCP endpoint, a Vault-backed token, a NetworkPolicy, a forward in the Frontier MCP Registry, and a registry row. That is the repeatable template for onboarding any MCP-compliant server — vendor, SaaS, or partner — into the Federal Frontier Platform.

See also: MCP Servers Overview, Frontier MCP Registry, Secrets Management.