- Reliability 8/20
- Only server.json and the README are available — there is no test suite, CI workflow, or any reproducible evidence of the MCP init/tool-list handshake, so per the static calibration rule reliability cannot exceed 12. More importantly, the manifest and README directly contradict each other: the npm/pypi package's environment-variable description states 'Search runs locally, no key required,' while the README repeatedly insists search actually runs server-side on letsfg.co and requires a 90-day Bearer token obtained via `letsfg auth` first. This contradiction about where the core function even executes means the manifest's minimal declared surface (one optional LETSFG_API_KEY) cannot be trusted to reflect the real runtime dependency chain — external HTTP polling (60–90s), a Stripe setup session, and other undeclared dependencies — with no verifiable evidence of failure handling.
- Security and permissions 9/20
- The manifest's own declared credential surface is modest and reasonable (LETSFG_API_KEY marked isSecret, isRequired=false, used only for the paid Developer API). However, the README's recommended path (`letsfg auth`) requires attaching a payment method via Stripe for nearly every operation — including hotel 'search' — and this real payment data-flow is completely undisclosed in server.json, a meaningful transparency gap between the declared manifest and actual behavior. The docs also self-report a lack of idempotency protection on booking ('do not retry book_hotel blindly — it double-books and double-charges'), with no protocol-level confirmation or idempotency key, relying purely on documentation warnings. This does not cross the red line for irreversible-payment-without-confirmation (booking still requires an explicit call with passenger/payment details), but real monetary actions (full ticket price, 10% non-refundable hotel deposit) without protocol-level confirmation or dedup safeguards push this above a merely 'main risks visible' baseline into deduction territory.
- Maintenance 9/20
- The repository's license field is NOASSERTION while the README badge and body both claim 'MIT License' with a LICENSE link — a direct contradiction suggesting a missing/malformed SPDX header or an inaccurate claim, a clear governance/transparency flaw. Beyond that, none of the provided material shows a changelog, security-response channel, or dependency-update policy; stars and open-issue counts are discovery signals only and are not credited toward this score. The date-based versioning scheme (2026.4.9) suggests some cadence of updates, but without verifiable governance evidence this lands in the 'active but with versioning/governance gaps' mid-low range.
- Documentation 11/20
- The README is extensive — covering install, a three-path comparison table, CLI command reference, pricing, architecture diagrams, and Python/JS code samples — which is strong for static material. However, it contains substantive self-contradictions that squarely hit the 'docs contradict capability' deduction: (1) the manifest claims search 'runs locally, no key required' while the README insists search requires a server-side Bearer token; (2) the license is claimed as MIT while the repo's license field is NOASSERTION; (3) the README itself opens by admitting an earlier revision's description of an MPP charge at unlock time 'never shipped,' meaning the documentation has previously misrepresented actual capability. These contradictions undercut the docs' reliability as verifiable evidence and keep the score below the 'usable but with hidden assumptions' tier.
- Setup experience 9/20
- Per the static calibration rule, without real CI workflows plus committed tests covering key paths, setup cannot exceed 15. On the surface, MCP client configuration is minimal (`npx -y letsfg-mcp`), but functional search and booking require an additional in-session `letsfg auth` step that performs a Stripe-based payment-method setup and writes a local token file (~/.letsfg/config.json) — none of which is reflected in server.json's environmentVariables. Critically, the manifest's claim that 'search runs locally, no key required' contradicts the README's description of a cloud-token-gated search flow, meaning a user relying solely on the declared manifest configuration would likely end up with non-functional search — undermining the clarity and robustness of the setup path.