Connection problems

Locate the failing part of the connection

Separate client-to-Durin authentication from Durin-to-provider access. A client that cannot authenticate needs a different investigation from a client that connects successfully but receives no tools or an upstream error.

• Record the client and version, the Durin workspace, the affected connection, the time, and the displayed error.
• Confirm whether the failure occurs during client setup, provider consent, discovery, the connection test, or a tool call.
• Use a small reviewed read to reproduce the issue where possible. Avoid retrying a write whose outcome is uncertain.

MCP client cannot connect to Durin

If your MCP client fails to connect to Durin, check these steps:

1. Verify the endpoint URL is correct — copy it fresh from the Durin app.
2. Confirm the transport type matches what your client expects (HTTP or Streamable HTTP).
3. Authenticate the MCP client with the same active Durin account that owns the endpoint; signing into the web app alone does not authenticate the client.
4. Try a different MCP client to isolate whether the issue is client-specific.
5. Check the Durin activity log for any connection-level errors.

Authentication failures

When you see authentication errors connecting your MCP client:

1. Re-authenticate by signing out and back in to the MCP client.
2. Clear any cached tokens in your MCP client configuration.
3. Verify your Durin organization membership has not been revoked.
4. Check that your MCP endpoint has not changed (it is tied to your user and workspace).

Upstream provider not responding

If requests reach Durin but the upstream provider times out or returns errors:

1. Check the upstream provider's status page for outages.
2. Verify the connection's OAuth grant has not expired — re-authorize if needed.
3. Check that the upstream workspace or organization still exists.
4. Review the connection detail page for provider-specific error messages.

Custom server setup fails before discovery

The current MCP setup and execution path requires Streamable HTTP and the supported provider OAuth flow. Legacy SSE transport cannot complete this path. Custom request headers can be saved in a draft but are not forwarded by the current MCP execution path.

If the server requires an API key in one of those custom headers, saving the value is not evidence that Durin sent it. Confirm transport and authentication compatibility with the server owner before repeating setup. The endpoint must also be a public HTTPS destination allowed by the connection checks.

Sign-in succeeds but testing or activation is blocked

Read the first unresolved checkpoint in the connection guide. Discovery may succeed while a tool remains unreviewed, lacks a verified validator, or targets a resource outside its allowed boundary. A past successful test can also become invalid after the bound context changes.

1. Confirm the intended provider account and current grant.
2. Review the tool status and the resource used by the read-only test.
3. Check the member’s team access and any current policy restriction.
4. Repeat the required test after resolving the cause, then inspect a fresh activation preview.

Collect enough evidence for the next person

If you need help, provide the error text, timestamp, client version, connection identifier, and the setup step that failed. Include the corresponding activity or request identifier when one exists. Say whether another reviewed read on the same connection works.

This lets the administrator distinguish an identity mismatch, an unavailable provider, an unsupported setup path, and a policy decision without guessing. Keep the installation state unchanged unless disabling it is part of the intended response.