fix(mcp): coerce corrupted consecutiveFailures instead of crashing the whole server list

[waleedlatif1]

Summary

• Active production incident: 81 MCP servers across 69 workspaces currently have their entire "MCP tools" settings page blanked with "Response failed contract validation" — confirmed via direct DB query against the production database
• Root cause: updateServerStatus() in lib/mcp/service.ts only fell back to a default status config when the whole statusConfig column was null, not when it was a real-but-incomplete object (e.g. the column's '{}' default on server creation). This made consecutiveFailures undefined, undefined + 1 evaluate to NaN, and JSON.stringify(NaN) persist as a literal null the first time a freshly-created server hit a connection failure
• That corrupted null then failed the server-list contract's Zod parse client-side (consecutiveFailures: z.number() rejects null) — since the response is an array, one bad server blanks the entire list for the whole workspace
• Fixed in two places: service.ts now normalizes the read-back status config so consecutiveFailures is always a real number going forward; the contract schema also coerces any non-number consecutiveFailures (including already-corrupted null rows) to the default of 0, so all 69 currently-broken workspaces self-heal immediately on next page load — no DB migration needed

Type of Change

• Bug fix (production incident)

Testing

• Verified the fix against the exact corrupted production data shape with a standalone Zod parse script ({consecutiveFailures: null} → {consecutiveFailures: 0, ...}, no longer throws)
• Existing lib/mcp/service.test.ts suite passes (11/11)
• bun run check:api-validation passes

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jul 11, 2026 5:33pm

[cursor]

PR Summary

Medium Risk
Touches MCP connection status persistence and list API validation for a user-facing settings surface; changes are narrow and defensive with low blast radius beyond healing corrupt rows.

Overview
Fixes a production bug where one MCP server with a bad statusConfig could make the entire workspace MCP server list fail contract validation and render blank.

updateServerStatus now builds currentConfig from partial stored JSON so consecutiveFailures is always a number before + 1, preventing NaN / null from being written when new servers (e.g. default {} config) hit their first failure.

The MCP server list contract preprocesses consecutiveFailures so any non-number (including already-corrupted null) defaults to 0, so existing bad rows self-heal on the next list load without a migration.

^{Reviewed by Cursor Bugbot for commit 95f9625. Configure here.}

[greptile-apps]

Greptile Summary

This PR makes MCP server status parsing tolerate corrupted failure counts. The main changes are:

• Adds a schema preprocess for consecutiveFailures.
• Defaults non-number failure counts to 0 during contract parsing.
• Normalizes partial persisted statusConfig before updating server status.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.
• The update path now handles the empty-object and null failure-count cases described in the incident.

Important Files Changed

Filename	Overview
apps/sim/lib/api/contracts/mcp.ts	Adds defensive parsing for corrupted consecutiveFailures values in the MCP server status contract.
apps/sim/lib/mcp/service.ts	Builds a normalized status config before incrementing or resetting MCP server failure counts.

_{Reviews (1): Last reviewed commit: "fix(mcp): coerce corrupted consecutiveFa..." | Re-trigger Greptile}