[exa-mcp-server]: align server.json with ai.exa/exa namespace + auto-publish workflow

[devin-ai-integration]

Summary

Fixes the registry namespace mismatch (server.json said io.github.exa-labs/exa-mcp-server, but all 6 published versions on the MCP registry are under ai.exa/exa via DNS auth on exa.ai) and adds an auto-publish workflow.

server.json

• $schema: 2025-07-09 → 2025-12-11
• name: io.github.exa-labs/exa-mcp-server → ai.exa/exa
• remote.type: sse → streamable-http (matches what's already published; mcp.exa.ai/mcp is streamable-http)
• version: 3.2.1 → 3.2.2 (3.2.1 is already on npm)

package.json

• mcpName: io.github.exa-labs/exa-mcp-server → ai.exa/exa (registry validates this against server.json name at publish time)
• version: 3.2.1 → 3.2.2

.github/workflows/publish-mcp-registry.yml (new)
Auto-publishes to npm + MCP registry on every GitHub Release. Requires two repo secrets:

• NPM_TOKEN — npm publish token for exa-mcp-server
• MCP_REGISTRY_DNS_PRIVATE_KEY — hex ed25519 private key matching the v=MCPv1; ... TXT record on exa.ai

Why this is needed

Current state on registry: latest is ai.exa/exa@3.1.3 (Dec 2025). npm latest is exa-mcp-server@3.2.1. Without these fixes, mcp-publisher publish fails because the namespace in server.json doesn't match the DNS-auth namespace, and would create a duplicate entry under the GitHub auth namespace.

Manual steps that still need to happen (outside this PR)

1. Rotate the DNS TXT record on exa.ai to a fresh ed25519 keypair (the original private key was lost).
2. Add NPM_TOKEN and MCP_REGISTRY_DNS_PRIVATE_KEY to repo secrets.
3. Cut a GitHub Release for v3.2.2 to trigger the workflow (or use workflow_dispatch).

Review & Testing Checklist for Human

• Confirm ai.exa/exa is the namespace we want long-term (vs. switching to io.github.exa-labs/exa-mcp-server via GitHub auth — would require re-publishing all 6 versions under the new name)
• Verify streamable-http is actually the remote type served at mcp.exa.ai/mcp (it's what every published version on the registry uses)
• Once secrets are configured, dry-run the workflow via workflow_dispatch before cutting a release
• After publish, check curl -s "https://registry.modelcontextprotocol.io/v0/servers?search=ai.exa/exa&version=latest" | jq shows 3.2.2 with isLatest: true

Notes

The smithery postinstall hook (smithery: not found) prints a warning during npm install locally but doesn't block the lockfile update or publish. The hook resolves correctly in CI where smithery is available.

Link to Devin session: https://app.devin.ai/sessions/e62162290c89447d84908809d82f8b11

---

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
exa-mcp-server	Ready	Preview, Comment	Apr 28, 2026 5:24pm

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[devin-ai-integration]

Devin Review found 2 potential issues.

View 3 additional findings in Devin Review.

[devin-ai-integration]

🟡 Incomplete version bump: src/index.ts still reports version 3.2.1

The PR bumps the version from 3.2.1 to 3.2.2 in package.json and server.json, but src/index.ts:85 still hardcodes version: "3.2.1" in the McpServer constructor. This means the MCP server will report itself as version 3.2.1 to clients, which is inconsistent with the published package version 3.2.2. The new workflow's consistency check (publish-mcp-registry.yml:29-30) only validates package.json vs server.json, so it won't catch this drift either.

Prompt for agents

The version was bumped to 3.2.2 in package.json and server.json, but src/index.ts:85 still has version: "3.2.1" hardcoded in the McpServer constructor. Update that line to "3.2.2". Also consider reading the version from package.json at runtime (or using a build step) to avoid this class of bug in the future. Similarly, gemini-extension.json:3 also has the old version "3.2.1" and should be updated.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🟡 workflow_dispatch version input is accepted but never used

The version input defined at .github/workflows/publish-mcp-registry.yml:8-11 is never referenced by any step in the workflow. Its description says "Version to publish (must match package.json + server.json)" suggesting it should be validated or applied, but no step reads ${{ inputs.version }}. If a user provides a version via manual dispatch, it is silently ignored, which is misleading.

Prompt for agents

The workflow_dispatch input 'version' at .github/workflows/publish-mcp-registry.yml:8-11 is defined but never used by any step. Either remove the input entirely, or add validation in the 'Verify version consistency' step (around line 28) to check that inputs.version (when provided) matches the version in the JSON files. For example, add something like: if [ -n "${{ inputs.version }}" ] && [ "${{ inputs.version }}" != "$PKG_VERSION" ]; then echo '::error::Provided version does not match package.json'; exit 1; fi

---

Was this helpful? React with 👍 or 👎 to provide feedback.