DEV Community

Session zero
Session zero

Posted on

Two Bugs That Ate Two Hours: Registering an Apify MCP Server on MCP-Hive

#mcp #apify #ai #api

After last week's post about MCPize blockers, I had a working MCP server and nowhere to list it.

Then I found MCP-Hive: a marketplace launching May 11 with a "Project Ignite" program for the first 100 founding providers — zero platform fees, priority placement. The deadline was implied. I had the server. I tried to register it.

Two hours later, I had succeeded. But I'd hit two bugs along the way that aren't documented anywhere.

The Setup

My MCP server runs on Apify in Standby mode. Apify's Standby feature keeps an actor running continuously and routes HTTP requests to it — perfect for MCP's server-sent event model.

The actor is naver-place-mcp: a server that exposes three tools for searching Korean places, fetching reviews, and pulling photos from Naver Place (Korea's dominant local search platform).

MCP-Hive's remote deployment option looked straightforward: provide an endpoint URL and optional authentication. That's it.

Bug #1: The Underscore-to-Hyphen Trap

Apify Standby endpoints follow this URL format:

https://{username}--{actor-name}.apify.actor/{path}
Enter fullscreen mode Exit fullscreen mode

My Apify username is oxygenated_quagmire (with an underscore). So I assumed the endpoint would be:

https://oxygenated_quagmire--naver-place-mcp.apify.actor/mcp
Enter fullscreen mode Exit fullscreen mode

I tested it. Without a token, I got:

{
  "error": {
    "type": "api-token-missing",
    "message": "This is a standby Actor. To use it, you need to pass your Apify API token."
  }
}
Enter fullscreen mode Exit fullscreen mode

Good — the server exists, just needs auth. I added the token:

curl -X POST "https://oxygenated_quagmire--naver-place-mcp.apify.actor/mcp?token=apify_api_..."
Enter fullscreen mode Exit fullscreen mode

Response:

{
  "error": {
    "type": "record-or-token-not-found",
    "message": "Actor or Actor task was not found or access denied"
  }
}
Enter fullscreen mode Exit fullscreen mode
  1. With a valid token. I confirmed the token worked fine for API calls (listing actors, checking builds). I verified actorStandby.isEnabled: true via the Apify API. I tried Bearer headers instead of query params. Still 404.

Then I tried replacing the underscore with a hyphen:

https://oxygenated-quagmire--naver-place-mcp.apify.actor/mcp
Enter fullscreen mode Exit fullscreen mode

It worked immediately.

Lesson: Apify subdomain URLs normalize underscores to hyphens. Your username in the Apify console might show underscores, but the Standby endpoint URL uses hyphens. If you have an underscore in your username, this will silently 404 with a valid token — the error message gives no indication that the domain is wrong.

Bug #2: The Accept Header Requirement

Once I had the right URL, I ran a proper MCP initialize request:

curl -X POST "https://oxygenated-quagmire--naver-place-mcp.apify.actor/mcp?token=..." \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{...}}'
Enter fullscreen mode Exit fullscreen mode

Response:

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32000,
    "message": "Not Acceptable: Client must accept both application/json and text/event-stream"
  }
}
Enter fullscreen mode Exit fullscreen mode

MCP's Streamable HTTP transport (which replaced SSE in April 2025) requires the client to declare it accepts both JSON and server-sent events. Standard Content-Type: application/json alone isn't enough.

The fix:

curl -X POST "https://oxygenated-quagmire--naver-place-mcp.apify.actor/mcp?token=..." \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{...}}'
Enter fullscreen mode Exit fullscreen mode

This returned a valid MCP initialize response confirming three tools: naver_place_search, naver_place_reviews, naver_place_photos.

Lesson: MCP Streamable HTTP requires Accept: application/json, text/event-stream. This isn't obvious if you're testing with curl. Most HTTP clients don't set this by default. Test your endpoint with the right headers before trying to register anywhere.

The Registration

With a confirmed working endpoint, MCP-Hive registration took about 5 minutes:

  1. Log in → Provider Dashboard → "Register MCP Server"
  2. Fill in name, description, categories
  3. Pricing: Pay per Call, $0.01
  4. Deployment Type: Remote
  5. Endpoint URL: https://oxygenated-quagmire--naver-place-mcp.apify.actor/mcp
  6. Authentication: API Key (Bearer Token), Authorization header, Bearer {apify_token}
  7. Submit for Review

Status is now Pending. MCP-Hive says tool descriptions are collected automatically when the server connects — so the tool list should populate after review.

What MCP-Hive's Project Ignite Offers

For context on why I bothered:

  • Launch date: May 11, 2026
  • Founding Provider program: First 100 providers, zero platform fees, priority marketplace placement
  • Business model: Pay-per-call. MCP-Hive handles the payment infrastructure and routes requests from AI applications to your server.
  • Requirements: A working remote endpoint (HTTP/SSE) with optional auth

If you have an existing MCP server — even one running on Apify Standby — this is a low-effort registration. The hard part is usually the endpoint itself, not the marketplace form.

The Quick Reference

For anyone going through the same process:

Apify Standby URL format:

https://{username-with-hyphens}--{actor-name}.apify.actor/{path}
Enter fullscreen mode Exit fullscreen mode

Underscores in usernames become hyphens in subdomain URLs.

MCP Streamable HTTP test:

curl -X POST "{your-endpoint}" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer {token}" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'
Enter fullscreen mode Exit fullscreen mode

A valid response looks like:

event: message
data: {"result":{"protocolVersion":"2024-11-05","capabilities":{"tools":{"listChanged":true}},...},"jsonrpc":"2.0","id":1}
Enter fullscreen mode Exit fullscreen mode

If you get 406 Not Acceptable, you're missing the Accept header.
If you get 404 with a valid token, check for underscores in your subdomain URL.

The server is registered. Whether it generates revenue after May 11 is a separate question — but the blockers were two lines of code away from obvious.

Top comments (0)