Discovery regressions: sparse email search + empty get_alternatives for valid slugs

[supertrained]

Summary

The core discovery path still feels broken for obvious email-service use cases.

Repro

1) MCP alternatives returns empty for a valid slug

npx -y @modelcontextprotocol/inspector --cli npx -y rhumb-mcp@latest \
  --method tools/call \
  --tool-name get_alternatives \
  --tool-arg slug=sendgrid

Response:

{"alternatives":[]}

2) The underlying service detail does have alternatives

curl https://api.rhumb.dev/v1/services/sendgrid

Response includes:

• postmark (8.9)
• resend (8.8)
• klaviyo (8.7)
• aws-ses-v3 (8.6)
• mailgun (8.5)

So the data exists, but the MCP/user-facing alternatives flow is not surfacing it.

3) Email discovery queries are weak/sparse

# API
curl 'https://api.rhumb.dev/v1/search?q=email%20sending'
# => 1 result: aws-ses-v3

curl 'https://api.rhumb.dev/v1/search?q=send%20email'
# => 1 result: google-workspace-api

curl 'https://api.rhumb.dev/v1/search?q=email%20API%20for%20agents'
# => 0 results

Equivalent MCP repro:

npx -y @modelcontextprotocol/inspector --cli npx -y rhumb-mcp@latest \
  --method tools/call \
  --tool-name find_services \
  --tool-arg 'query=email sending'

Returned only AWS SES.

Expected

• get_alternatives(sendgrid) should return the alternatives already present on the service object.
• Natural first-run queries around email (email sending, send email, email API for agents) should return multiple obvious candidates like SendGrid, Resend, Postmark, Mailgun, SES.

Actual impact

This makes the first dogfood path feel unreliable in one of the most common categories:

• search is too sparse for obvious queries
• alternatives goes blank even when the underlying service page clearly has alternatives

That’s a bad first impression for both MCP users and direct API users.