Skip to main content
Question

Remote SecOps MCP server: all SOAR-backed tools return "Internal error encountered." on one instance, while SIEM tools work fine

  • July 21, 2026
  • 1 reply
  • 6 views

kataro
Forum|alt.badge.img

Hi all,

We operate multiple Google SecOps instances and use the managed remote MCP server (chronicle.<region>.rep.googleapis.com/mcp, negotiated protocol version 2025-11-25) from an AI agent. On one specific instance, every SOAR-backed tool fails, while the same tools work fine on our other instance. This is not agent-specific — it reproduces with direct, bare MCP tool calls (minimal arguments, no LLM involved).

Symptom — on the affected instance, with only customerId / projectId / region / pageSize: 1:

tool: list_cases
→  isError: true, "Internal error encountered."

Same result with/without filter ("Status='OPENED'") and orderBy — all argument variants fail identically.

Side-by-side (identical bare calls on both instances):

 

 

What we've ruled out:

1. Caller permissions — the same service account runs all SIEM tools successfully on the affected instance, so MCP authorization passes. And when we deliberately call with an SA that lacks access, we get an explicit PERMISSION_DENIED with a troubleshooter URL — a clearly different failure shape.
2. The SOAR instance itself — direct REST calls to the SOAR's own API (AppKey auth) return HTTP 200 on the affected instance. The SOAR is healthy.
3. Argument syntax — the control instance returns "invalid argument" for the same under-specified calls, i.e. its backend at least reaches argument validation. The affected instance fails with an opaque Internal error before validation.

Our working hypothesis: the affected instance's SIEM↔SOAR unified-platform binding is not (fully) provisioned, so the MCP backend cannot route case-management calls to SOAR — while the control instance, provisioned as a unified platform from the start, routes fine.

Questions:
1. Has anyone seen this pattern — SIEM MCP tools fine, all SOAR MCP tools returning bare "Internal error encountered."?
2. Is there a way to check/verify the SIEM↔SOAR binding state for an instance from the customer side (console or API)?
3. Is enabling that binding something we can self-serve, or does it require a provisioning request through support/partner channels?

Thanks!

1 reply

kentphelps
Community Manager
Forum|alt.badge.img+12
  • Community Manager
  • July 22, 2026

What stage of SOAR Migration are you in?  Take a look at this guide in the community:
 

SOAR API Migration
Rather than the old SOAR APIs, which used api keys, the hosted MCP servers have standardized to use the Chronicle (REST) APIs. That allows you to use Application Default Credentials (ADC) and it allows you to specify users entitlements via IAM. The migration from SOAR API to Chronicle API is fully described in: SOAR migration overview but you CAN use the OneMCP tools before migrating: the SIEM tools do NOT require this migration, so you can use those right away.