different-ai/openwork · warning

MCP_PROVIDER_AUTH_REQUIRED

MCP_PROVIDER_AUTH_REQUIRED

Error message

MCP_PROVIDER_AUTH_REQUIRED

What it means

providerAuthorizationClassification in external-mcp-diagnostics.ts produces a diagnostic classification (not an exception) meaning the external MCP provider requires per-user account authorization before the capability can be used. The gateway has connected to the provider but the member's account is not linked, so calls are rejected with category provider_authorization_required.

Source

Thrown at ee/apps/den-api/src/capability-sources/external-mcp-diagnostics.ts:485

function providerDeclaredErrorFromJson(
  value: unknown,
  phase: ExternalMcpDiagnosticPhase,
): ProviderDeclaredErrorEvidence | null {
  if (Array.isArray(value)) {
    for (const item of value) {
      const evidence = providerDeclaredErrorFromEnvelope(item, phase)
      if (evidence) return evidence
    }
    return null
  }
  return providerDeclaredErrorFromEnvelope(value, phase)
}

function providerAuthorizationClassification(connectUrl: string): Classification {
  return {
    phase: "PROVIDER_AUTHORIZATION",
    category: "provider_authorization_required",
    code: "MCP_PROVIDER_AUTH_REQUIRED",
    retryable: false,
    actionOwner: "member",
    operatorAction: "Connect your account for this provider using its sign-in link, then retry this capability.",
    connectUrl,
  }
}

function providerDeclaredErrorClassification(): Classification {
  return {
    phase: "PROVIDER_EXECUTION",
    category: "provider_declared_error",
    code: "MCP_PROVIDER_DECLARED_ERROR",
    retryable: false,
    actionOwner: "provider_admin",
    operatorAction: "Look up the provider-declared JSON-RPC error code with the provider, then correct the downstream condition and retry.",
  }
}

View on GitHub (pinned to 2b7df46e8a)

Solutions

  1. Open the connectUrl from the diagnostic and complete the provider's sign-in/OAuth flow, then retry the capability
  2. If the token expired or was revoked, re-authorize via the same connect link
  3. Verify with the org admin that the provider connection is enabled for your account
  4. After re-authenticating, re-run search_capabilities/execute_capability to confirm resolution
Defensive patterns

Strategy: try-catch

Validate before calling

// Before executing a capability, check prior diagnostics/connection state:
// if (connection.diagnostics.some(d => d.code === "MCP_PROVIDER_AUTH_REQUIRED")) {
//   prompt user to open connection.connectUrl and sign in
// }

Type guard

function needsProviderAuth(d: { code: string; connectUrl?: string }): d is { code: "MCP_PROVIDER_AUTH_REQUIRED"; connectUrl: string } {
  return d.code === "MCP_PROVIDER_AUTH_REQUIRED" && typeof (d as { connectUrl?: string }).connectUrl === "string"
}

Try / catch

try {
  await executeCapability(capability, input)
} catch (err) {
  if (err instanceof Error && err.message.includes("MCP_PROVIDER_AUTH_REQUIRED")) {
    console.log("Connect your provider account:", diagnostic.connectUrl)
    // surface sign-in link to the member, then retry after authorization
  } else throw err
}

Prevention

When it happens

Trigger: A capability backed by an external MCP provider is executed while the requesting member has not completed OAuth/account linking for that provider; the gateway classifies the failure with connectUrl pointing to the provider's sign-in flow.

Common situations: First use of a connector before sign-in; an OAuth token was revoked or expired server-side; an admin added a new provider that members have not yet linked; sign-in flow was abandoned midway.

Related errors


AI-assisted analysis of different-ai/openwork@2b7df46e8a (2026-09-01). Data as JSON: /api/errors/ffc2fee8a75a6a63. Report an issue: GitHub.