Azure MCP tool calls fail with 'invalid character \'S\'' via MCP gateway

[dulalbert]

Summary

When running Azure MCP tool calls through gh-aw MCP gateway, calls fail with:

calling "tools/call": invalid character 'S' looking for beginning of value

Related upstream issue: microsoft/mcp#1373

Environment

• gh aw version: v0.50.4
• Workflow engine: copilot
• MCP gateway (awmg) version: v0.1.5
• Azure MCP image: mcr.microsoft.com/azure-sdk/azure-mcp:latest
• Runner OS: ubuntu-latest

Minimal Repro (gh-aw markdown)

Sanitized: real subscription ID and service name replaced with placeholders.

---
on:
  workflow_dispatch:
    inputs:
      ai_search_service:
        description: Azure AI Search service name
        required: false
        default: <AZURE_SEARCH_SERVICE_NAME>
      ai_search_subscription:
        description: Azure subscription ID for AI Search
        required: false
        default: <AZURE_SUBSCRIPTION_ID>

permissions:
  contents: read

network:
  allowed:
    - defaults
    - login.microsoftonline.com
    - management.azure.com
    - "*.search.windows.net"

tools:
  startup-timeout: 180

mcp-servers:
  azure:
    container: mcr.microsoft.com/azure-sdk/azure-mcp
    version: latest
    env:
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
      AZURE_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    allowed:
      - search
---
# Repro
Run Azure MCP `search` router with:
- command: `search_index_query`
- parameters.service: `${{ github.event.inputs.ai_search_service }}`
- parameters.index: `markdown-chunks`
- parameters.query: `Blibberwock`
- parameters.top: `5`

Repro tool payload

{
  "name": "search",
  "arguments": {
    "command": "search_index_query",
    "intent": "Query index for test string",
    "parameters": {
      "service": "<AZURE_SEARCH_SERVICE_NAME>",
      "index": "markdown-chunks",
      "query": "Blibberwock",
      "top": 5
    }
  }
}

Actual

Gateway surfaces parser error:

• invalid character 'S' looking for beginning of value

Often followed by session/client closing errors on subsequent calls.

Expected

• Successful tool execution, or
• A structured JSON-RPC error from backend with diagnostic detail.

Impact

This is opaque in gh-aw workflows because parser-level failure hides the backend cause and makes triage difficult.

Suggested gh-aw improvements

• Include sanitized raw response prefix/body when JSON parse fails.
• Include backend server ID + tool command context in surfaced error.
• Add hint/link for known Azure MCP non-JSON response behavior (see linked upstream issue).

Additional context

The same Azure MCP server setup works via VS Code Copilot MCP integration. This points to a gh-aw/MCP-gateway path issue rather than credentials/service configuration alone.

Update: Non-Search Azure Tools Also Fail On latest

New reproduction run confirms this is not specific to search_index_query.

• Run: 22475353360
• Workflow engine: copilot
• Azure MCP image: mcr.microsoft.com/azure-sdk/azure-mcp:latest

Executed Azure MCP smoke tests before search:

1. documentation (learn: true) -> invalid character 'S' looking for beginning of value
2. subscription_list -> invalid character 'S' looking for beginning of value
3. group_list -> invalid character 'S' looking for beginning of value (and session closing)

Because all three non-search calls fail with the same parser-level error, this strongly suggests a broader Azure MCP response-format/runtime issue on this path, not a search-command-specific issue.

[pelikhan]

You need to report this upstream to the azure sdk team.

[dulalbert]

Thanks for the quick answer @pelikhan, I updated the issue upstream

I think this is also an error-handling problem in the gateway path.

Important context: these failures are from official gh-aw examples and not from random MCP:

• .github/workflows/shared/mcp/azure.md
• .github/workflows/shared/mcp/chroma.md
• docs: https://github.github.com/gh-aw/guides/mcps/

Backend failures and failure classification/diagnostics are too generic to debug quickly, which hinders developper experience:

1. invalid character 'S' looking for beginning of value path
   This indicates non-JSON-RPC content was returned on a JSON-RPC channel.
   Current error hides the offending payload/source, so debugging is guesswork.
   The MCP server works when using it with GH Copilot / Codex.
2. Chroma official example path
   I also have an issue when running the official Chroma example/import. The MCP server fails to initialize and the run ends with Chroma tools missing, so the workflow cannot execute the expected
   chroma_* steps.
   This should fail fast with a clear runtime/transport error for that server instead of surfacing later as generic tool-missing symptoms.

Can we improve this with:

• explicit error class for non-JSON-RPC backend responses,
• sanitized raw prefix in logs/error details to show what was actually received, and not only half the error?
• explicit error class for launcher/runtime failures (e.g. command not found),