NPX package broken on Linux - HTTP endpoint only exposes 2 tools instead of 7

[0xReLogic]

Issue Description

The exa-mcp-server package has different behavior between Windows and Linux, and the HTTP endpoint is missing most tools.

Environment

• OS: Linux (Ubuntu)
• Node: v20.19.5
• NPM: v10.8.2
• Package: [email protected]

Problem 1: NPX Package Fails on Linux

When trying to run the package via npx on Linux:

npx -y exa-mcp-server

Error:

npm error could not determine executable to run

The package.json defines the bin as:

{ "exa-mcp-server": ".smithery/stdio/index.cjs" }

But this file appears to be missing or inaccessible in the published package on Linux systems.

Expected: Package should work on Linux just like it does on Windows (where it successfully exposes 7 tools)

Problem 2: HTTP Endpoint Missing Tools

As a workaround, I tried using the HTTP endpoint:

{
  "type": "http",
  "url": "https://mcp.exa.ai/mcp",
  "headers": {
    "X-API-Key": "<api-key>"
  }
}

Result: Only 2 tools are exposed:

• web_search_exa
• get_code_context_exa

Expected: All 7 tools should be available:

• web_search_exa
• get_code_context_exa
• company_research_exa
• crawling_exa
• linkedin_search_exa
• deep_researcher_start
• deep_researcher_check

Configuration Tested

{
  "command": "npx",
  "args": [
    "-y",
    "exa-mcp-server"
  ],
  "env": {
    "EXA_API_KEY": "<api-key>"
  }
}

Logs

npm error could not determine executable to run
npm error A complete log of this run can be found in: /home/azureuser/.npm/_logs/2025-11-10T12_15_55_633Z-debug-0.log

From npm debug log:

15 verbose stack Error: could not determine executable to run
16 verbose pkgid [email protected]

Request

Please fix the Linux compatibility issue with the npx package. The bin entry point seems to be broken on Linux systems while it works fine on Windows.

If you need help debugging , I can have this fixed in 30 minutes lol.

[0xReLogic]

Update: Found the Root Cause

So I dug into the source code and found what's happening.

The Problem

The published npm package has a corrupted or incompatible .smithery/stdio/index.cjs file that fails on Linux but somehow works on Windows. When running npx -y exa-mcp-server, Linux throws:

npm error could not determine executable to run

The Workaround (that actually works)

I cloned the repo, ran npm install (which triggers the build), and boom - it works perfectly on Linux with all 7 tools.

Here's the config that works:

{
  "command": "node",
  "args": [
    "/path/to/exa-mcp-server/.smithery/stdio/index.cjs",
    "tools=get_code_context_exa,web_search_exa,company_research_exa,crawling_exa,linkedin_search_exa,deep_researcher_start,deep_researcher_check"
  ],
  "env": {
    "EXA_API_KEY": "your-api-key"
  }
}

You Guys Needs to Be Fixed

The issue is in your publish process. The .smithery/stdio/index.cjs file in the published package is broken on Linux. Possible causes:

1. Line ending issues (CRLF vs LF)
2. Shebang not being added correctly during build
3. File permissions not preserved during publish
4. The build script in prepublishOnly might be failing silently

Suggested Fix

Check your package.json build script:

"build:stdio": "smithery build src/index.ts --transport stdio -o .smithery/stdio/index.cjs && echo '#!/usr/bin/env node' | cat - .smithery/stdio/index.cjs > temp && mv temp .smithery/stdio/index.cjs && chmod +x .smithery/stdio/index.cjs"

This might not work correctly on all platforms during npm publish. Consider:

• Using a proper build tool that handles cross-platform builds
• Testing the published package on Linux before releasing
• Adding a postinstall script to fix permissions if needed

Let me know if you want me to submit a PR with a fix.

[divideby0]

Hey @0xReLogic, I did some investigation via Claude Code and it looks like latest published package might actually be fine — shebang present, LF line endings, correct permissions, file exists. The real culprit is most likely npm cache from earlier broken versions.

Looking at the git history, there was a flurry of releases between v3.0.0-3.0.5 (all on Oct 1-2) where the bin path kept changing: Looking at the git history, there was a flurry of releases between v3.0.0-3.0.5 (all on Oct 1-2) where the bin path kept changing:

Version	bin path	Actual file	Works?
v3.0.0-3.0.2	./stdio/.smithery/index.cjs	.smithery/stdio/index.cjs	Nope (path mismatch)
v3.0.3-3.0.4	./.smithery/index.cjs	.smithery/index.cjs	Yes
v3.0.5+	.smithery/stdio/index.cjs	.smithery/stdio/index.cjs	Yes

If npm cached metadata from v3.0.0-3.0.2, it would try to run a file that doesn't exist — hence "could not determine executable."

I hit the same issue on macOS with a cached older version. Clearing the cache fixed it.

Try this:

npm cache clean --force
npx -y [email protected]

Also pushed a small fix to use ./ prefix in the bin path for better cross-platform compatibility.

Re: why cloning works — the prepare script builds everything fresh, bypassing the registry entirely.

---

Disclosure: Used Claude Code to investigate this (analyzed npm tarballs, git history, hex dumps of the published files, etc). This is a summary of those findings.

[divideby0]

See PR #90 for prefix fix mentioned above.