fix(fleet): api.ferrfleet.com serves no /v1 routes, every mcp-fleet tool 404s

[BryanFRD]

Every ferrlabs-fleet tool fails with API error: HTTP 404. The bearer is accepted (a rejected token would give 401, as ferrlabs-track and ferrlabs-growth do), so this is not auth: the routes the MCP calls are not served.

Reproduction

Authorize ferrlabs-fleet, then call list_agents -> API error: HTTP 404.

Probing the API directly

api.ferrfleet.com answers on /health but 404s on every /v1 path tried, unauthenticated:

/health                  -> 200   {"status":"ok"}
/v1/agents               -> 404
/v1/runs                 -> 404
/agents                  -> 404
/v1/fleet/agents         -> 404
/v1/marketplace/agents   -> 404

/v1/runs matters: it is the other half of the sub-MCP surface (packages/mcp-fleet/src/tools/runs.ts), so this is not one mistyped path in agents.ts. Nothing under /v1 responds.

An unauthenticated request to a route that exists but requires auth should return 401. Returning 404 on every one suggests the router never reaches the application, which points at deployment or ingress rather than at the handler code.

Two candidate causes

1. api.ferrfleet.com is not serving the FerrFleet API. Health is answered by something upstream (ingress or a placeholder) while the application is not routed, not deployed, or mounted under a different prefix.
2. The API is up but mounts its routes under a prefix packages/mcp-fleet does not use. In that case FLEET_API_URL in packages/mcp-fleet/src/api-base.ts:1 and the paths in agents.ts / runs.ts need to match whatever is actually served.

Confirm which before changing anything here: if the API is simply not deployed, no client change is correct.

Why it went unnoticed

scripts/smoke.ts only boots @ferrlabs/mcp (#246), and the sub-MCP tools have no tests (#160). Nothing in CI would have caught an entire product API being unreachable.

[BryanFRD]

The client half is fixed in #323, merged. The deployment half is what keeps this open.

What was wrong on the client

The API dropped the /v1 prefix and now negotiates its contract by date through ferrlabs-api-version. @ferrfleet/mcp was still calling /v1/agents and /v1/runs with no version header. It now calls /agents and /runs and sends x-ferrfleet-api-version: 2026-08-04, overridable through FERRFLEET_API_VERSION.

Both hypotheses in the original report were half right: the paths were wrong, and separately the routes are not reachable.

What is still wrong, and it is not the client

Production serves /health and nothing else. With the correct version header:

/health                -> 200   {"status":"ok"}
/agents                -> 404
/runs                  -> 404
/v1/agents             -> 404
/api/agents            -> 404
/marketplace/agents    -> 404
/credits               -> 404
/settings              -> 404

Empty bodies on all of them, which is axum saying no route matched rather than a handler refusing.

The negotiation middleware, on the other hand, is definitely deployed: x-ferrfleet-api-version: 2020-01-01 returns 410 Gone, and every response carries X-Api-Version-Served: 2026-08-04.

That combination is the useful signal. build_router in FerrFleet-Cloud/api/src/lib.rs applies the version layer to the same router that merges agents, runs, marketplace, credits, settings and ten more. A build where the layer answers but none of the merged routes exist is not a build of that function. Either the deployed image predates the route surface, or something upstream terminates /health and the version layer while never forwarding the rest.

Worth checking which image tag api.ferrfleet.com actually runs before touching any code: the repo says the routes are there, and the client now matches the repo.