Summary
Several public surfaces disagree with the live product state after the email OTP rollout.
Repro / evidence
1) Quickstart says 21 MCP tools, live server exposes 16
Quickstart copy (https://rhumb.dev/quickstart) says:
"21 tools available: find_services, get_score, get_alternatives, get_failure_modes, execute_capability, and more."
Live MCP server:
npx -y @modelcontextprotocol/inspector --cli npx -y rhumb-mcp@latest --method tools/list
Actual result: 16 tools.
2) Quickstart shows rhumb_live_..., live signup issued rhumb_...
Dogfood signup flow:
POST /v1/auth/email/request-code
- receive OTP email successfully
POST /v1/auth/email/verify-code
Live response issued an API key with prefix:
But Quickstart still shows examples like:
-H "X-Rhumb-Key: rhumb_live_..."
3) Public service-count copy disagrees across pages
- Homepage hero says 1000 scored services
- Homepage lower copy says 1,038 scored services
llms.txt also says 1,038 scored services
4) MCP install/config examples are inconsistent
- README uses
npx -y rhumb-mcp@latest
- Quickstart MCP config currently shows command
npx with args ["rhumb-mcp@latest"]
That may be okay in some contexts, but it no longer matches the safer README pattern and adds first-run ambiguity.
Expected
Public docs and onboarding copy should match the live surface:
- accurate MCP tool count
- accurate API key prefix
- consistent service-count claims
- one canonical MCP launch/config example
Impact
None of these are backend outages, but together they create avoidable trust friction exactly where a new user is trying to decide whether Rhumb is precise and reliable.
Summary
Several public surfaces disagree with the live product state after the email OTP rollout.
Repro / evidence
1) Quickstart says 21 MCP tools, live server exposes 16
Quickstart copy (
https://rhumb.dev/quickstart) says:Live MCP server:
Actual result: 16 tools.
2) Quickstart shows
rhumb_live_..., live signup issuedrhumb_...Dogfood signup flow:
POST /v1/auth/email/request-codePOST /v1/auth/email/verify-codeLive response issued an API key with prefix:
But Quickstart still shows examples like:
-H "X-Rhumb-Key: rhumb_live_..."3) Public service-count copy disagrees across pages
llms.txtalso says 1,038 scored services4) MCP install/config examples are inconsistent
npx -y rhumb-mcp@latestnpxwith args["rhumb-mcp@latest"]That may be okay in some contexts, but it no longer matches the safer README pattern and adds first-run ambiguity.
Expected
Public docs and onboarding copy should match the live surface:
Impact
None of these are backend outages, but together they create avoidable trust friction exactly where a new user is trying to decide whether Rhumb is precise and reliable.