All contributors have signed the CLA. Thank you! ✅
_{Posted by the CLA Assistant Lite bot.}

Greptile Summary

This PR fixes authentication for the Exa MCP server by adding support for API key headers. The RemoteMcpConfig type now includes an optional headers field, and websearch_exa reads EXA_API_KEY from the environment to pass as the x-api-key header.

Key Changes:

• Extended RemoteMcpConfig type with optional headers?: Record<string, string> field in src/mcp/index.ts:12
• Added conditional header injection in websearch_exa configuration using process.env.EXA_API_KEY
• Headers field follows the same pattern as McpRemoteConfig in the Claude Code MCP loader (src/features/claude-code-mcp-loader/types.ts:27)

Implementation:
The fix correctly handles the optional API key - when EXA_API_KEY is not set, headers will be undefined, allowing the MCP to work without authentication if the server supports it. The type definition aligns with the existing McpRemoteConfig interface used in the Claude Code compatibility layer.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The changes are minimal, well-scoped, and follow existing patterns in the codebase. The type definition matches the existing McpRemoteConfig interface, and the conditional header logic safely handles missing environment variables
• No files require special attention

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant ENV as Environment Variables
    participant Config as websearch_exa.ts
    participant Type as RemoteMcpConfig Type
    participant Handler as config-handler.ts
    participant MCP as Exa MCP Server

    Note over ENV,MCP: MCP Connection Initialization Flow

    ENV->>Config: Read EXA_API_KEY
    Config->>Config: Check if EXA_API_KEY exists
    alt EXA_API_KEY is set
        Config->>Config: Set headers: { "x-api-key": EXA_API_KEY }
    else EXA_API_KEY not set
        Config->>Config: Set headers: undefined
    end
    
    Config->>Type: Return config object with optional headers
    Note over Config,Type: Config conforms to<br/>RemoteMcpConfig interface
    
    Handler->>Config: Call createBuiltinMcps()
    Handler->>Handler: Merge builtin MCPs into config.mcp
    
    Handler->>MCP: Connect to https://mcp.exa.ai/mcp
    alt Headers present
        Handler->>MCP: Include x-api-key header
        MCP->>MCP: Authenticate with API key
        MCP-->>Handler: Connection successful
    else No headers
        Handler->>MCP: Connect without headers
        MCP-->>Handler: May timeout or succeed<br/>(depending on server config)
    end

Greptile found no issues!

From now on, if a review finishes and we haven't found any issues, we will not post anything, but you can confirm that we reviewed your changes in the status check section.

_{This feature can be toggled off in your Code Review Settings by deselecting "Create a status check for each PR".}

I have read the CLA Document and I hereby sign the CLA

Hi @raydocs, thanks for the fix! 👋

I've merged dev into your branch to resolve the conflicts. Here's what changed while your PR was open:

File Rename

• websearch-exa.ts → websearch.ts
• MCP name changed from websearch_exa → websearch

This happened in PR #549 which restored Exa support after it was temporarily removed due to timeout issues (the exact issue your fix addresses!).

Type Change

Your original PR used McpName[] for disabledMcps, but I kept the current string[] from dev because:

• Allows graceful handling of old MCP names (e.g., websearch_exa)
• Supports custom MCP names without type errors
• Changed intentionally in commit 72445d2

Your header fix is still the correct solution - it just needed adapting to the new file structure. Thanks for the contribution! 🙏