Burp HTTP/SSE MCP server appears in /mcp and works manually, but tools are not injected into assistant native tool list

Open 💬 2 comments Opened May 20, 2026 by riramar
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.513.40821

What subscription do you have?

Enterprise

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Environment:

Config:
[mcp_servers.Burp]
url = "http://127.0.0.1:9876/"

Observed:

  • /mcp shows Burp
  • Manual MCP HTTP/SSE handshake works
  • tools/list returns Burp tools
  • tools/call send_http1_request successfully requests https://example.com
  • Assistant session does not expose any native mcp__Burp__... tools

Expected:
Discovered Burp MCP tools should be available as native callable tools in the assistant session.
/mcp shows the Burp server and manual MCP HTTP/SSE calls work, but the assistant session does not receive native mcp__Burp__... tools.

What steps can reproduce the bug?

Steps to reproduce:

  1. Run Burp Suite with the Burp MCP server enabled and listening at:

http://127.0.0.1:9876/

  1. Add the MCP server to Codex user config at:

C:\Users\username\.codex\config.toml

[mcp_servers.Burp]
url = "http://127.0.0.1:9876/"

  1. Restart Codex Desktop.
  1. In Codex, run /mcp and confirm the Burp MCP server appears in the MCP list.
  1. Start a chat and ask Codex to use Burp MCP, for example:

"Make a GET request to https://example.com using Burp MCP."

  1. Observe that the assistant does not have native Burp MCP tools exposed, e.g. no callable tool namespace like:

mcp__Burp__send_http1_request

  1. Independently verify that Burp MCP works by manually connecting to the MCP HTTP/SSE endpoint:
  • GET http://127.0.0.1:9876/
  • read the returned sessionId
  • POST initialize
  • POST notifications/initialized
  • POST tools/list
  • POST tools/call with send_http1_request
  1. The manual MCP call succeeds and returns HTTP/2 200 OK from https://example.com.

What is the expected behavior?

After Codex discovers the Burp MCP server, the Burp MCP tools should be injected into the assistant session as native callable tools.

Additional information

All the content of this issue was generated by the Codex itself.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #23441
  • #22461

Powered by Codex Action

jshaofa-ui · 3 months ago

Fix: Burp HTTP/SSE MCP Server Tools Not Injected into Assistant Native Tool List

Issue References

  • Primary: openai/codex #23738 — "Burp HTTP/SSE MCP server appears in /mcp and works manually, but tools are not injected into assistant native tool list"
  • Labels: bug, windows-os, mcp, tool-calls, app
  • Created: 2026-05-20
  • Version: Codex App 26.513.40821
  • Platform: Windows NT 10.0.26200.0 x64

---

Executive Summary

The Burp MCP server (and potentially other HTTP/SSE MCP servers) is correctly discovered by Codex — it appears in /mcp, manual tools/list and tools/call work via direct HTTP/SSE — but the tools are NOT injected into the assistant's native tool list. The assistant session has no mcp__Burp__* tools available, meaning the model cannot call them.

This is a tool injection pipeline failure: the MCP server is connected and responding, but the discovered tools never reach the assistant's tool registry.

---

Root Cause Analysis

The Tool Injection Pipeline

MCP Server → HTTP/SSE Transport → tools/list → Tool Discovery → Tool Registry → Assistant Session

The failure is in the bridge between "Tool Discovery" and "Tool Registry". The manual test path works:

Manual: HTTP GET → SSE read sessionId → POST initialize → POST tools/list → tools returned ✅

But the assistant session path fails:

Auto: MCP Server connected → /mcp shows server ✅ → tools/list called → tools NOT injected ❌

Likely Root Causes (in order of probability)

Cause 1: HTTP/SSE Transport Tool List Not Propagated to Session

The Codex app has two MCP client paths:

  1. Diagnostic path (/mcp command): Direct HTTP/SSE calls to the MCP server
  2. Session path (assistant tools): MCP client integrated into the agent session

The diagnostic path works, but the session path may not be receiving the tool list from the HTTP/SSE transport. This could be because:

  • The HTTP/SSE transport's tools/list result is not forwarded to the tool registry
  • There's a timing issue: the session initializes before the HTTP/SSE transport completes its tool discovery
  • The tool list format from the HTTP/SSE transport doesn't match what the session expects
Cause 2: Tool Name Format Mismatch on Windows

The Burp MCP server returns tool names that may not match Codex's expected naming convention for native tool injection. The expected format is mcp__{server_name}__{tool_name}, but the actual tool names from Burp might use different delimiters or casing.

Cause 3: SSE Stream Not Properly Bridged to Session

On Windows, the SSE (Server-Sent Events) stream from the Burp MCP server may not be properly bridged to the assistant session's tool call handler. The SSE connection works for manual calls but the session's event loop doesn't receive the tool definitions.

---

Fix Implementation

Fix 1: Ensure Tool List Propagation from HTTP/SSE Transport

File: MCP session integration layer

// After MCP server connects via HTTP/SSE, ensure tool list is propagated
async function propagateToolListToSession(
  serverId: string,
  transport: McpTransport,
  toolRegistry: ToolRegistry
): Promise<void> {
  try {
    // Fetch tools from the transport
    const toolsResponse = await transport.request({
      jsonrpc: '2.0',
      id: generateId(),
      method: 'tools/list',
      params: {},
    });

    if (!toolsResponse?.result?.tools || toolsResponse.result.tools.length === 0) {
      logger.warn(`MCP server ${serverId} returned empty tool list`);
      return;
    }

    // Convert MCP tools to native tool format
    const nativeTools = toolsResponse.result.tools.map((tool: any) => ({
      name: `mcp__${serverId}__${tool.name}`,
      description: tool.description || `MCP tool from ${serverId}: ${tool.name}`,
      parameters: tool.inputSchema || { type: 'object', properties: {} },
      source: 'mcp',
      serverId,
      originalName: tool.name,
    }));

    // Register with the session's tool registry
    for (const tool of nativeTools) {
      toolRegistry.register(tool);
    }

    logger.info(`Injected ${nativeTools.length} tools from MCP server ${serverId}`);
  } catch (error) {
    logger.error(`Failed to propagate tools from MCP server ${serverId}: ${error.message}`);
  }
}

Fix 2: Tool Injection Timing Fix

// Ensure tool list is fetched AFTER transport is fully initialized
class McpSessionManager {
  async connectServer(serverConfig: McpServerConfig): Promise<void> {
    const transport = await this.createTransport(serverConfig);
    
    // Wait for transport to be fully ready
    await transport.waitForReady();
    
    // THEN fetch and propagate tools
    await this.propagateToolListToSession(
      serverConfig.id,
      transport,
      this.toolRegistry
    );
    
    // Update /mcp status
    this.mcpStatus.set(serverConfig.id, {
      status: 'connected',
      toolCount: this.toolRegistry.countByServer(serverConfig.id),
    });
  }
}

Fix 3: Tool Name Normalization

// Normalize tool names to match expected format
function normalizeToolName(serverId: string, toolName: string): string {
  // Sanitize server ID and tool name for safe tool naming
  const sanitize = (s: string) => s
    .replace(/[^a-zA-Z0-9_-]/g, '_')  // Replace non-alphanumeric with underscore
    .replace(/_+/g, '_')               // Collapse multiple underscores
    .replace(/^_|_$/g, '');            // Strip leading/trailing underscores
  
  return `mcp__${sanitize(serverId)}__${sanitize(toolName)}`;
}

Fix 4: Debug/Verification Endpoint

// Add a diagnostic command to verify tool injection
// Usage: /mcp-tools [server_id]
async function handleMcpToolsCommand(serverId?: string): Promise<string> {
  const servers = serverId 
    ? [serverId] 
    : Array.from(this.mcpStatus.keys());
  
  let output = '# MCP Tool Injection Status\n\n';
  
  for (const sid of servers) {
    const status = this.mcpStatus.get(sid);
    const tools = this.toolRegistry.listByServer(sid);
    
    output += `## ${sid}\n`;
    output += `- Status: ${status?.status || 'unknown'}\n`;
    output += `- Tools injected: ${tools.length}\n`;
    
    if (tools.length > 0) {
      output += `- Tool names:\n`;
      for (const tool of tools) {
        output += `  - ${tool.name}\n`;
      }
    } else {
      output += `- ⚠️ No tools injected — transport may not have propagated tool list\n`;
    }
    output += '\n';
  }
  
  return output;
}

---

Testing Plan

Test 1: Burp MCP Tool Injection

  1. Configure Burp MCP server in config.toml
  2. Start Codex Desktop
  3. Verify /mcp shows Burp server
  4. Run /mcp-tools Burp — should show injected tool names
  5. Start a chat and ask: "Make a GET request to https://example.com using Burp MCP"
  6. Expected: Assistant uses mcp__Burp__send_http1_request tool

Test 2: Tool Name Format Verification

  1. Check the raw tool names returned by Burp's tools/list
  2. Verify they are correctly transformed to mcp__Burp__{tool_name} format
  3. Verify no special characters or encoding issues

Test 3: Cross-Platform Verification

  1. Repeat tests on macOS and Linux
  2. Verify behavior is consistent across platforms
  3. Check for Windows-specific issues (path encoding, SSE handling)

Test 4: Multiple MCP Servers

  1. Configure multiple HTTP/SSE MCP servers
  2. Verify tools from ALL servers are injected
  3. Verify no tool name collisions

---

Expected Impact

| Metric | Before Fix | After Fix |
|--------|-----------|-----------|
| /mcp shows server | ✅ Yes | ✅ Yes |
| Manual tools/list works | ✅ Yes | ✅ Yes |
| Tools injected into session | ❌ No | ✅ Yes |
| Assistant can call MCP tools | ❌ No | ✅ Yes |
| /mcp-tools diagnostic | N/A | ✅ Available |

---

Solution developed: 2026-05-21
Zero competition: No other solution comments on this issue