Skip to main content

Case Study: Sable MCP Initiative

This case study shows how Second Opinion was used to validate an architecture decision and identify missing requirements before implementation began.

Context​

Initiative: Add OAuth 2.1 authentication to Sable MCP so Claude Desktop and Claude.ai users can connect to their portfolio data.

The Challenge:

  • Sable MCP already exists (14 tools, embedded in Next.js on Vercel)
  • Currently uses org_id as a parameter (no auth)
  • Need per-user authentication for financial data
  • Two architectural options to evaluate

The Architecture Decision​

We had two viable paths:

OptionDescriptionProsCons
Path ASupabase Edge Functions + mcp-liteAll-in Supabase, native OAuthDeno rewrite, brand new tech
Path BKeep Vercel + add Supabase OAuthMinimal changes, proven platformTwo platforms to manage

We chose Path B based on research showing:

  1. Supabase OAuth 2.1 is still in beta
  2. mcp-lite on Edge Functions just launched (Jan 2026)
  3. Existing code works - why rewrite?
  4. Two unknowns (beta OAuth + new Edge Functions) = too risky for financial data

Using Second Opinion to Validate​

Before proceeding, we used Second Opinion in validate mode to get an external assessment.

The Request​

{
  "context": "Adding OAuth 2.1 authentication to Sable MCP server for Claude Desktop/Claude.ai users to connect to their portfolio/trading data.",

  "proposal": "Keep MCP server on Vercel (existing code). Add Supabase OAuth 2.1 as authorization server. Use mcp-handler package with withMcpAuth() wrapper. Validate tokens via Supabase getUser() API. Extract user_id/org_id from JWT claims. RLS policies enforce data isolation.",

  "mode": "validate",

  "file_paths": [
    "/home/dshanklin/repos/aic-holdings/Sable/aic-sable-sb/app/api/[transport]/route.ts",
    "/home/dshanklin/repos/aic-holdings/Sable/aic-sable-sb/lib/mcp/tools.ts"
  ]
}

The Response​

Confidence: 7/10 - Proceed with changes

The tool validated our approach but identified critical gaps:

What It Validated​

  • Architecture is technically feasible
  • Data isolation strategy is robust
  • Existing code is well-structured
  • Path B (Vercel + Supabase OAuth) is the right choice

Missing Components Identified​

GapPriorityWhy We Missed It
Token refresh flowHighFocused on initial auth, not maintenance
Rate limiting for OAuth endpointsHighAssumed Supabase handles this
Error handling for expired tokensHighHappy path thinking
Audit logging for auth eventsMediumNot security-focused enough
Token revocation endpointMediumForgot users need to disconnect
Load testing with auth enabledMediumPerformance was afterthought

Risks Flagged​

RiskProbabilityImpact
Supabase OAuth 2.1 beta instabilityMediumHigh
Single point of failure if Supabase Auth is downLowHigh
RLS policy mistakes could leak dataLowCritical

Key Insight: The "Obvious" Gaps​

The most valuable feedback wasn't about our architecture choice - it was about what we forgot to include.

Token refresh flow - We designed the initial OAuth flow but didn't think about what happens when tokens expire. Without this, users would need to re-authenticate frequently.

Rate limiting - We assumed Supabase would handle this, but the MCP endpoint itself needs protection against abuse.

Revocation - Users need to be able to disconnect Claude from their account. We had no plan for this.

The Outcome​

Before Second Opinion​

Requirements captured: 2

  • Per-user OAuth 2.1 authentication (critical)
  • Data isolation via RLS

After Second Opinion​

Requirements captured: 7 (added 5)

  • Per-user OAuth 2.1 authentication (critical)
  • Data isolation via RLS
  • Token refresh flow (high)
  • Rate limiting for OAuth endpoints (high)
  • Graceful error handling for invalid/expired tokens (high)
  • Auth event audit logging (medium)
  • Token revocation endpoint (medium)

Risks documented: 3

  • Supabase OAuth beta instability
  • Single point of failure
  • RLS policy mistakes

Success criteria defined: 4

  • Auth latency < 100ms p95
  • Zero cross-user data leaks
  • OAuth flow works end-to-end from Claude Desktop
  • Users can revoke access from Sable web UI

What We Learned​

1. Use Second Opinion Before Starting Implementation​

We caught these gaps before writing any code. If we had discovered the token refresh issue during development, it would have required rearchitecting.

2. Pass Real File Paths​

The tool read our actual MCP implementation and gave specific feedback about our code structure. Generic advice is less useful.

3. "Validate" Mode is Perfect for Go/No-Go Decisions​

We didn't need alternatives or challenges at this point - we had already made the architecture decision. We needed validation with gap analysis.

4. Create Tickets From Every Finding​

Every gap identified became a requirement in the initiative. The risks became documented risks with mitigations. Nothing was lost.

5. 7/10 Confidence is Actually Good​

The tool gave 7/10 with "proceed with changes" - not a perfect score, but a clear signal that the approach is sound with known improvements needed.

The Initiative Today​

After incorporating Second Opinion feedback:

Sable MCP Initiative
├── Requirements: 7 (2 critical, 3 high, 2 medium)
├── Risks: 3 (all with mitigations)
├── Success Criteria: 4
├── Constraints: 1 (data isolation)
├── Assumptions: 1 (Supabase OAuth stability)
└── Status: Ready for implementation

Try It Yourself​

When validating your next architecture decision:

mcpammer_second_opinion(
  context="[What you're building and why]",
  proposal="[Your proposed approach]",
  mode="validate",
  file_paths=["[Relevant code files]"]
)

Then add every finding to your initiative as:

  • Requirements (for gaps)
  • Risks (for concerns)
  • Success criteria (for validation points)