Support MCP Provider Exceptions

Use this page for high-friction providers that should not be handled with generic reconnect advice.

Microsoft Family

The Microsoft family is one of the most important exception groups in Neotask.

Affected providers include:

  1. Microsoft Teams
  2. Microsoft 365
  3. Azure
  4. Azure DevOps
  5. PowerBI

Support Position

Treat these as Microsoft Entra manual OAuth setups unless current product truth says otherwise.

Step-by-Step Support Flow

  1. Confirm which Microsoft provider is failing.
  2. Confirm the caller is using the correct Microsoft tenant.
  3. Open the provider setup panel in Neotask and copy the exact callback URL shown there.
  4. In Microsoft Entra, create or open the application registration for that provider.
  5. Add the Neotask callback URL as a Web redirect URI.
  6. Copy the Application (client) ID.
  7. Create or copy the client secret if the provider requires one.
  8. Paste those values into Neotask.
  9. Re-run consent in the correct Microsoft tenant and account.

Common Failure Pattern

The caller connected the wrong Microsoft tenant or approved the wrong account, so the provider looks connected but the expected workspace data is missing.

Vercel

Support Position

Vercel is currently a manual-fallback exception. Do not keep telling the caller to retry the managed DCR path if it has already failed.

Support Flow

  1. Confirm the caller is working on Vercel specifically.
  2. If the managed flow already failed, move to the provider-specific fallback path instead of repeating the same connect attempt.
  3. Collect the exact callback URL and failure behavior before escalating if the fallback path is still blocked.

NetSuite

Support Position

NetSuite is a manual-credentials provider, not a normal hosted OAuth flow.

Step-by-Step Support Flow

  1. Gather the NetSuite account ID.
  2. Gather the consumer key and consumer secret from the NetSuite integration record.
  3. Gather the token ID and token secret from token-based authentication.
  4. Confirm the account-specific NetSuite host or instance path is correct.
  5. Enter those fields in Neotask exactly as shown.
  6. Re-test the provider after saving every field.

Common Failure Pattern

The auth material is correct, but the account-specific host or account ID is wrong.

JetBrains

Support Position

JetBrains is a local-runtime case. Do not force it into standard hosted OAuth troubleshooting.

Step-by-Step Support Flow

  1. Confirm the caller is using a supported JetBrains IDE.
  2. Confirm the IDE is open.
  3. Confirm the required plugin or local integration path is active.
  4. Re-check the tool availability only after the local runtime is actually running.

Common Failure Pattern

The caller expects cloud-style OAuth behavior, but the missing piece is the local IDE/plugin runtime.

Salesforce

Support Position

Salesforce needs careful handling because the hosted MCP endpoint is still treated as beta-sensitive in product truth.

Step-by-Step Support Flow

  1. Confirm the provider is Salesforce.
  2. Use the exact callback URL from the Neotask setup panel.
  3. In Salesforce App Manager, create or open the Connected App.
  4. Enable OAuth settings and paste the callback URL exactly.
  5. Add the required API and refresh scopes shown in Neotask.
  6. Copy the Consumer Key and Consumer Secret into Neotask.
  7. Save the app and allow time for Salesforce propagation before retrying.

Common Failure Pattern

The app is configured correctly, but the hosted MCP path or propagation delay still causes confusion. If the setup is correct and it still fails, escalate instead of improvising.

Indeed

Support Position

Indeed should be treated as a manual or pre-registered OAuth path rather than an open managed DCR path.

Support Flow

  1. Confirm the caller is working with Indeed.
  2. Use the exact callback URL from Neotask.
  3. Confirm the caller is using the provider’s approved manual OAuth path.
  4. If they are expecting a one-click managed DCR flow, correct that expectation and move them to the manual setup checklist.

Custom URL First Providers

Some providers fail because the wrong tenant URL is saved before auth even starts.

High-value examples:

  1. Benchling Replace the tenant placeholder with the real Benchling tenant URL before saving.
  2. Visier Replace the vanity placeholder with the real tenant URL before continuing.
  3. Any provider with baseUrl, instanceUrl, workspaceUrl, or organizationUrl Save the correct URL first, then continue with auth.

When To Escalate

Escalate instead of guessing when:

  1. The provider is marked managed_dcr_broken or unreachable.
  2. The caller already completed the documented setup exactly.
  3. The correct scope is being used, but the runtime still fails.
  4. The provider needs company-specific or admin-specific guidance that is not yet documented.