Published MCP package is stale/regressed vs current product surface

[supertrained]

Weekly dogfood 2026-04-27 found the published npm MCP package does not match the current public product surface.

Repro

node tmp/dogfood-mcp-2026-04-27b.mjs
# script uses @modelcontextprotocol/sdk stdio transport against:
# npx -y rhumb-mcp@0.8.2

Observed

• serverInfo.version is still 0.0.1 while npm package is 0.8.2.
• Tool list exposes only 4 tools:
  • find_tools
  • get_score
  • get_alternatives
  • get_failure_modes
• Expected docs/current public copy talk about a larger Resolve-capable MCP surface, and previous dogfood saw 16 tools.
• The requested/user-facing find_services tool is not present; calling it returns Tool find_services not found.
• Calling get_score({ slug: "stripe" }) returned a soft failure payload:

{
  "slug": "stripe",
  "aggregateScore": null,
  "executionScore": null,
  "accessScore": null,
  "confidence": 0,
  "tier": "unknown",
  "explanation": "Failed to fetch score: fetch failed",
  "freshness": "unknown"
}

• find_tools({ query: "email sending", limit: 5 }) returned { "tools": [] } even though the REST API returns AWS SES for the same obvious query.
• get_alternatives({ slug: "sendgrid" }) still returns [] while REST /v1/services/sendgrid returns populated alternatives.

Expected

The published MCP package should either:

1. expose the current documented tool surface and Resolve tools, or
2. public docs should be tightened to the actual 4-tool package until the broader surface is republished.

At minimum, the package should not fail the canonical Stripe score lookup while the REST endpoint works.

Impact

This is a first-run trust break for agent users. The npm install path is likely the first thing developers try, and right now it looks older than the website/API and fails on core discovery/score paths.